Больше ответов - меньше вопросов.
Apr. 4th, 2012 03:42 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
astikhin
На днях пришел мне вопрос относительно вот этого поста, который написал без малого год назад в котором меня попросили описать более подробно - почему с проектами происходят такие вот неприятные вещи. Ответ на этот вопрос достачно простой и он никаким образом не связан с технической стороной дела. Нет, конечно когда будет плохое техническое исполнение хорошего плана, то фиаско гарантированно, но речь идет несколько о другом - когда начинают оправдывать неудачу проекта только ее технической реализацией.
Для того, что бы был более понятен механизм "провала операции" ее надо рассмотреть во всех деталях. Итак, предположим, некая компания Z решила что она жить не может без какой-нибудь супер-навороченной системы планирования ресурсами (управления предприятем) или, на худой конец, системы документооборота. С чего обычно начинается проект? Как правило с подбора непосредственно системы, которую планируют внедрять на предприятии и с подрядчиков, которые могут выполнить работы в полном объеме и еще взять систему на гарантийную поддержку.
На этом этапе, как правило, осознанная работа заканчивается и начинается хождение по заколдованному кругу - "потратили деньги -> поставили систему -> она вроде бы работает, но от нее нет никакого толку -> сделайте что-нибудь". Сделать, обычно, уже ничего нельзя и не потому что системы или люди работающие на предприятии какие-то неправильные, а потому что вводные условия были изначально неверными.
Теперь постараемся разобраться почему так происходит и как этого избежать. Начать надо с того, что очень часто происходит внедрение ради самого внедрения и забывается главная цель - зачем, собственно говоря, нужно внедрение любой системы на любом предприятии. Ответить на этот вопрос означает ответить и, самое главное, понять - почему проваливаются проекты по внедрению сложных систем. Почему-то считается, что основная работа по внедрению - чисто техническая (поставить оборудование, настроить софт, обучить людей), но забывается, что главной задачей стоящей перед внедренцами является составление четкого плана прохождения информационных потоков внутри предприятия и подстройка системы под уже существующие потоки.
Именно от того, насколько четко и ясно представлен подобный "информационный план предприятия" напрямую зависит скорость и корректность внедрения любой системы. Если же этого не сделать на начальном этапе, то немного позже произойдет классическая ситуация - начнутся попытки (или прямое изменение) работы предприятия под внедряемую (внедренную) систему, а не усиление и упрощение уже существующего взаимодействия между разными структурными подразделениями. К чему это приводит в итоге? Приводит это к тому, что ресурсы предприятия начинают тратиться на подковерные игры между отделами в которых каждый будет стремиться спихнуть ответственность на других и компании, понятно дело, от таких раскладов ничего хорошего ждать не надо. На внедренцев, понятное дело, начинают смотреть как на "врагов рода человеческого", которых надо расстрелять в ближайшей подворотне (по крайней мере в фантазиях работников).
Теперь самое интересное - понимание того, как работают внутренние информационные потоки. Вот здесь-то обычно и выясняется, что вообще мало кто на предприятии понимает общий производственный цикл и может внятно объяснить, что "здесь-вот-так-вот, а здесь - вот-так-вот". Если таких людей нет - получается как в примере с судами штата Калифорния, если есть - то выходит некая "лоскутная" автоматизация разных подразделений, а затем "допиливание напильником" (еще не самый худший вариант) и интеграция в общую рабочую среду.
Вывод - чем больше ответов на начальном этапе работы над проектом - тем меньше вопросов к самому проекту перед его сдачей в эксплуатацию и в ходе последующей поддержки.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-04-04 04:50 pm (UTC)Потому как много ответом на вопросы, скажем без понимания, что компания находится в каменном веке с точки зрения бизнес-процессов, или чрезмерный разрыв между желаемым и действительным, и еще много чисто когнитивных особенностей также точно могут завалить проект, как фраза генерального - ну сделай нам крутую автоматизацию.
no subject
Date: 2012-04-04 05:30 pm (UTC)У меня был ответ "общего плана", исходя из своего собственного опыта и опыта смежников :) Хотя, по сути дела, использование стандартов, рекомендаций и методологий лишь _помогает_ описать поставленную на реализацию задачу и не заменяет собой _понимание сути_ происходящих на предприятии бизнес-процессов.
> Потому как много ответом на вопросы, скажем без понимания, что компания находится в каменном веке с точки зрения бизнес-процессов, или чрезмерный разрыв между желаемым и действительным, и еще много чисто когнитивных особенностей также точно могут завалить проект, как фраза генерального - ну сделай нам крутую автоматизацию.
Да, к сожалению, не без этого. Со своей точки зрения (как технических специалист) долго не мог понять - откуда в айтишных и около-айтишных кругах появилсь понятие "шаманство с бубном". Понятно, конечно, что это описание непонятных действий, но все же - откуда это появилось? Нашел ответ на этот вопрос, с моей точки зрения, в книге Торстейна Веблена "Теория праздного класса", а если быть точнее - то в главе, описывающий "анимистическое восприятие" действительности.
http://astikhin.livejournal.com/88248.html
В принципе, вывод автора очень простой, но это как раз тот случай, когда именно простота маскирует все трудности. Дело в том, что если человек _не понимает_ процессов, происходящих в мире (в нашем случае - в производстве) - он начинает "объяснять" это некими "высшими силами" и "магией" и, самое главное, не может _управлять и оптимизировать_ протекающие процессы.
Вот отсюда, на мой взгляд, и растут ноги у традиции "работать бубуном" и на корню рубить все процессы :)