Многие знают о ”культе карго” — удивительном явлении, имевшим место во время Второй мировой войны. В ходе боевых действий удаленные острова в Тихом океане вдруг стали стратегическим объектом, американцы построили на них военную базу, и местные туземцы были осчастливлены продуктами цивилизации, которые доставляли грузовые самолеты. Туземцы решили, что хитрый белый человек, который сам не производит никаких материальных ценностей, получает их напрямую от богов, выполняя загадочные ритуалы: марширует с палками по плацу, сидит возле ящика с антенной и молится на непонятном языке, призывая небесных птиц. Когда война окончилась, американцы оставили острова и их наивных обитателей. Когда же позднее на остров вернулись исследователи, они с удивлением обнаружили туземцев с нарисованными нашивками, марширующих по плацу и шаманов, призывающих ”карго” в деревянных наушниках перед муляжом радиостанции.
Культ карго, как оказалось, процветает не только на далеких островах, но и в кабинетах наших российских руководителей. Они уже много лет находятся в полной уверенности, что если надеть костюм, сесть в кресло, потратить деньги на дорогую импортную систему, то прилетят железные птицы и эффективность бизнеса автоматически повысится. Иногда на горизонте появляются также жрецы в деревянных наушниках с визитками различных консалтинговых компаний и оказывают посильную помощь в призвании железных птиц.
Но отвлечемся, пожалуй, от лирических аллегорий и поговорим о том, как и почему в проектах внедрения АСУ разные люди делают одни и те же ошибки, связанные с пренебрежением элементарными вещами. А именно, почему же заказчики проектов отказываются видеть собственные бизнес-процессы.
Начнем с наиболее вопиющего примера недальновидности заказчика, приведшего в итоге к суровому клинчу в проекте. Один государственный заказчик захотел систему управления сложным объектом. Он сформулировал подробные требования к функциям сбора данных и управления, к подсистемам, сформировал общие задачи на бизнес-уровне (”улучшение того-то”, ”уменьшение сего-то”), сформулировал требования к документированию, к надежности и еще много к чему в полном соответствии с ГОСТ 34Х.
Исполнитель взял эти требования и начал разрабатывать систему. Ранний прототип не вызвал у заказчика никаких особых претензий, и исполнитель продолжил разработку. Все было просто и логично: на экране было изображение объекта управления. Пользователь следил за состоянием объекта, выбирал различные элементы системы и мог проделать с ними определенные действия. В строгом соответствии с техническим заданием.
Самое интересное началось, когда заказчик начал думать об организации работ по эксплуатации объекта управления. Появились люди, которые стали задавать вопросы о том, как они должны будут работать, и кто что должен будет делать. Правильные вопросы, на которые у заказчика не было ответов. И он, руководствуясь очевидной для многих руководителей логикой, решил ”отжать” все, что необходимо для организации работ у разработчика, на свою беду не успевшего еще сдать систему и бежать с деньгами.
Начал он с регламентов новой службы. Исполнитель со вздохом снял людей с внедрения и направил их на разработку регламентов. Ссориться с заказчиком ему не хотелось. Потом заказчик решил, что организационное взаимодействие между людьми дело дюже сложное, требующее автоматизации. А потом он вдруг подумал, что неплохо бы сделать так, чтобы разрабатываемая система могла поддерживать процессы взаимодействия и гибко под них адаптироваться. Но тут уже возобладали законы физики, и исполнитель начал поглядывать в сторону леса, заранее оплакивая съеденный аванс.
Потому что, как оказалось, заказчику на самом деле нужна была автоматизация бизнес-процессов со всеми ее ”плюшками” — автоматической документацией, гибкой настройкой правил в графических редакторах, пользовательскими интерфейсами, которые создаются в реальном времени в зависимости от бизнес-правил… Исполнитель попробовал прикрыться ТЗ, но кого в наше время волнуют дурацкие бумажки? В итоге заказчик начал массированный троллинг, стал затягивать приемку работ, исполнитель столкнулся с финансовыми проблемами, сотрудники начали разбегаться, а проект оказался на грани закрытия. Успешный, между прочим, проект разработки АСУ.
Второй пример более мягкий, но не менее показательный. Крупный коммерческий заказчик захотел систему управления некими процессами. Исполнитель взял специализированную платформу и начал разработку. В ходе обследования выяснилось, что на самом деле процессов у заказчика никаких нет, а есть некая неформализованная деятельность, местами носящая хаотический и судорожно-конвульсивный характер. А так как формализация и постановка бизнес-процессов в состав работ не входила, пришлось выкручиваться разработчикам системы. Они почесали затылки и решили реализовать самый простой с их точки зрения вариант процесса. Заказчик, у которого, напомним, формализованных процессов не было, тоже почесал в затылке и принял предложенную форму процесса.
Веселье началось, когда сотрудники заказчика попробовали использовать систему. Оказалось, что процесс разработан неудобный, где-то слишком сложный, а где-то недостаточно детальный. Система, его реализующая, также оказалась совсем не той, что ожидал заказчик. Начался этап мучительной притирки, когда в ходе бесконечных торгов система стала приобретать требуемый вид, а заказчик начал выстраивать и описывать свои процессы. Сроки внедрения увеличились вдвое, затраты с обеих сторон также выросли до совершенно безобразных размеров. Проект заканчивали уже из чистого принципа, а после передачи очередного этапа почти вся измученная команда исполнителя уволилась.
Третий пример будет примером успешным. Заказчик захотел систему автоматизации бизнес-процесса. Техническое задание содержало требования как к самому процессу, так и к системе его автоматизирующей. Перед началом проекта заказчик провел обучение ключевых пользователей и участников команды внедрения, на котором показал принципы организации проектируемого бизнес-процесса, его преимущества. Из всей массы пользователей выделились несколько энтузиастов, которые и составили основу команды внедрения со стороны заказчика.
Две трети работ проекта были связаны с разработкой всяких инструкций, регламентов взаимодействия, матриц ответственности и тому подобного. Когда начались испытания системы, за компьютеры сели подготовленные и обученные пользователи. И хоть система оказалась достаточно скудной по функциональности, процесс стартовал сразу и без скрипа. Насколько мне известно, он успешно работает до сих пор (вот уже три с лишним года) безо всякого участия каких бы то ни было консультантов.
Подведем итоги. Первый пример нам демонстрирует ошибку в оценке первоначальной потребности заказчика. Опытные внедренцы должны не только читать ТЗ, но и смотреть на бизнес заказчика. Если у него нет описанных процессов, если в его организации не сформированы еще отделы, в которых будут работать будущие пользователи, то это первый тревожный звоночек. Рано или поздно такой заказчик захочет организовать эксплуатацию. И если он не станет у вас покупать консалтинговые услуги по организации процессов (а это почти всегда так), то вам все равно нужно заложить в архитектуру системы возможности для гибкой подстройки процессов в ходе внедрения и даже в ходе эксплуатации. Например, вместо SCADA системы реализовать систему на базе ESB или их симбиоз. Для заказчика это будет более дорогое решение и по платформе и по дополнительным мощностям, но за гибкость нужно платить, а риск оказаться в итоге у разбитого корыта требует принятие мер.
Второй случай демонстрирует нам проблему оторванности менеджмента от реальной ситуации. Заказывая вам систему, они искренне верят своим подчиненным, которые их уверяют в том, что все процессы уже давно описаны и ничего не нужно придумывать. Потом они признают свои ошибки, но вам-то от этого будет не легче. Рецепт тут тоже прост как три копейки. Спуститесь из офиса директора на производство. Посидите рядом с исполнителями, поговорите с ними как равный с равными. Они вам расскажут обо всех своих бедах — и что инструкций нет, и что бардак в управлении, и что в столовой мяса не докладывают. Послушайте их, да и включите в коммерческое предложение пункт ”актуализация бизнес-процессов”. Может быть, руководитель подумает, да и заплатит вам за эту работу. И это будут деньги, вложенные в правильное дело.
При чем же тут культ ”карго”? А при том, что мы, словно те туземцы, еще не оправились от нахлынувшей на нас из-за исчезнувшего железного занавеса волны разнообразных ”лучших практик”, ”передовых методик” и чудодейственных систем. Многие верят в то, что системы сами по себе решают проблемы бизнеса. Что купив, к примеру, ERP, предприятие уменьшит производственные запасы, а внедрив CRM сразу устранит риск увода клиентов лихими менеджерами.
Да, наличие рации необходимо для вызова железной птицы. Но вот для того, чтобы она действительно прилетела, нужно еще очень многое знать и о многом думать. Корни нашей проблемы находятся в нашем же прошлом. У руля предприятий стоят технари с технарским складом ума. Подавляющее большинство ИТ компаний тоже возглавляют технари. Технари верят в технику, в программы, в алгоритмы, в возможности систем. Технари с пренебрежением относятся к ”бумажкам”: регламентам и инструкциям. И уж совсем не верят технари в людей. А ведь люди это главный ресурс и главные средства производства ИТ-компаний. Люди — это основные шестеренки любых бизнес-процессов, независимо от уровня их автоматизации. Нельзя пренебрегать людьми в процессах и недооценивать их влияние на успех любого проекта. Те проекты, где понимают это, становятся украшением карьеры каждого участника команды.
Может быть, коллеги, я опять сказал какие-то банальности. Но я буду говорить банальности и очевидные вещи до тех пор, пока не канут в историю эти туземцы от бизнеса и их друзья-шаманы в деревянных наушниках.
P.S. от 23.09. Коллеги прислали ссылку на статью Михаила Плисса «Облом амбиций, или почему позиция CIO в России – карьерный тупик», которая прекрасно дополняет данный пост. Даже и добавить нечего. Читаю и почтительно молчу.
Культ карго, как оказалось, процветает не только на далеких островах, но и в кабинетах наших российских руководителей. Они уже много лет находятся в полной уверенности, что если надеть костюм, сесть в кресло, потратить деньги на дорогую импортную систему, то прилетят железные птицы и эффективность бизнеса автоматически повысится. Иногда на горизонте появляются также жрецы в деревянных наушниках с визитками различных консалтинговых компаний и оказывают посильную помощь в призвании железных птиц.
Но отвлечемся, пожалуй, от лирических аллегорий и поговорим о том, как и почему в проектах внедрения АСУ разные люди делают одни и те же ошибки, связанные с пренебрежением элементарными вещами. А именно, почему же заказчики проектов отказываются видеть собственные бизнес-процессы.
Начнем с наиболее вопиющего примера недальновидности заказчика, приведшего в итоге к суровому клинчу в проекте. Один государственный заказчик захотел систему управления сложным объектом. Он сформулировал подробные требования к функциям сбора данных и управления, к подсистемам, сформировал общие задачи на бизнес-уровне (”улучшение того-то”, ”уменьшение сего-то”), сформулировал требования к документированию, к надежности и еще много к чему в полном соответствии с ГОСТ 34Х.
Исполнитель взял эти требования и начал разрабатывать систему. Ранний прототип не вызвал у заказчика никаких особых претензий, и исполнитель продолжил разработку. Все было просто и логично: на экране было изображение объекта управления. Пользователь следил за состоянием объекта, выбирал различные элементы системы и мог проделать с ними определенные действия. В строгом соответствии с техническим заданием.
Самое интересное началось, когда заказчик начал думать об организации работ по эксплуатации объекта управления. Появились люди, которые стали задавать вопросы о том, как они должны будут работать, и кто что должен будет делать. Правильные вопросы, на которые у заказчика не было ответов. И он, руководствуясь очевидной для многих руководителей логикой, решил ”отжать” все, что необходимо для организации работ у разработчика, на свою беду не успевшего еще сдать систему и бежать с деньгами.
Начал он с регламентов новой службы. Исполнитель со вздохом снял людей с внедрения и направил их на разработку регламентов. Ссориться с заказчиком ему не хотелось. Потом заказчик решил, что организационное взаимодействие между людьми дело дюже сложное, требующее автоматизации. А потом он вдруг подумал, что неплохо бы сделать так, чтобы разрабатываемая система могла поддерживать процессы взаимодействия и гибко под них адаптироваться. Но тут уже возобладали законы физики, и исполнитель начал поглядывать в сторону леса, заранее оплакивая съеденный аванс.
Потому что, как оказалось, заказчику на самом деле нужна была автоматизация бизнес-процессов со всеми ее ”плюшками” — автоматической документацией, гибкой настройкой правил в графических редакторах, пользовательскими интерфейсами, которые создаются в реальном времени в зависимости от бизнес-правил… Исполнитель попробовал прикрыться ТЗ, но кого в наше время волнуют дурацкие бумажки? В итоге заказчик начал массированный троллинг, стал затягивать приемку работ, исполнитель столкнулся с финансовыми проблемами, сотрудники начали разбегаться, а проект оказался на грани закрытия. Успешный, между прочим, проект разработки АСУ.
Второй пример более мягкий, но не менее показательный. Крупный коммерческий заказчик захотел систему управления некими процессами. Исполнитель взял специализированную платформу и начал разработку. В ходе обследования выяснилось, что на самом деле процессов у заказчика никаких нет, а есть некая неформализованная деятельность, местами носящая хаотический и судорожно-конвульсивный характер. А так как формализация и постановка бизнес-процессов в состав работ не входила, пришлось выкручиваться разработчикам системы. Они почесали затылки и решили реализовать самый простой с их точки зрения вариант процесса. Заказчик, у которого, напомним, формализованных процессов не было, тоже почесал в затылке и принял предложенную форму процесса.
Веселье началось, когда сотрудники заказчика попробовали использовать систему. Оказалось, что процесс разработан неудобный, где-то слишком сложный, а где-то недостаточно детальный. Система, его реализующая, также оказалась совсем не той, что ожидал заказчик. Начался этап мучительной притирки, когда в ходе бесконечных торгов система стала приобретать требуемый вид, а заказчик начал выстраивать и описывать свои процессы. Сроки внедрения увеличились вдвое, затраты с обеих сторон также выросли до совершенно безобразных размеров. Проект заканчивали уже из чистого принципа, а после передачи очередного этапа почти вся измученная команда исполнителя уволилась.
Третий пример будет примером успешным. Заказчик захотел систему автоматизации бизнес-процесса. Техническое задание содержало требования как к самому процессу, так и к системе его автоматизирующей. Перед началом проекта заказчик провел обучение ключевых пользователей и участников команды внедрения, на котором показал принципы организации проектируемого бизнес-процесса, его преимущества. Из всей массы пользователей выделились несколько энтузиастов, которые и составили основу команды внедрения со стороны заказчика.
Две трети работ проекта были связаны с разработкой всяких инструкций, регламентов взаимодействия, матриц ответственности и тому подобного. Когда начались испытания системы, за компьютеры сели подготовленные и обученные пользователи. И хоть система оказалась достаточно скудной по функциональности, процесс стартовал сразу и без скрипа. Насколько мне известно, он успешно работает до сих пор (вот уже три с лишним года) безо всякого участия каких бы то ни было консультантов.
Подведем итоги. Первый пример нам демонстрирует ошибку в оценке первоначальной потребности заказчика. Опытные внедренцы должны не только читать ТЗ, но и смотреть на бизнес заказчика. Если у него нет описанных процессов, если в его организации не сформированы еще отделы, в которых будут работать будущие пользователи, то это первый тревожный звоночек. Рано или поздно такой заказчик захочет организовать эксплуатацию. И если он не станет у вас покупать консалтинговые услуги по организации процессов (а это почти всегда так), то вам все равно нужно заложить в архитектуру системы возможности для гибкой подстройки процессов в ходе внедрения и даже в ходе эксплуатации. Например, вместо SCADA системы реализовать систему на базе ESB или их симбиоз. Для заказчика это будет более дорогое решение и по платформе и по дополнительным мощностям, но за гибкость нужно платить, а риск оказаться в итоге у разбитого корыта требует принятие мер.
Второй случай демонстрирует нам проблему оторванности менеджмента от реальной ситуации. Заказывая вам систему, они искренне верят своим подчиненным, которые их уверяют в том, что все процессы уже давно описаны и ничего не нужно придумывать. Потом они признают свои ошибки, но вам-то от этого будет не легче. Рецепт тут тоже прост как три копейки. Спуститесь из офиса директора на производство. Посидите рядом с исполнителями, поговорите с ними как равный с равными. Они вам расскажут обо всех своих бедах — и что инструкций нет, и что бардак в управлении, и что в столовой мяса не докладывают. Послушайте их, да и включите в коммерческое предложение пункт ”актуализация бизнес-процессов”. Может быть, руководитель подумает, да и заплатит вам за эту работу. И это будут деньги, вложенные в правильное дело.
При чем же тут культ ”карго”? А при том, что мы, словно те туземцы, еще не оправились от нахлынувшей на нас из-за исчезнувшего железного занавеса волны разнообразных ”лучших практик”, ”передовых методик” и чудодейственных систем. Многие верят в то, что системы сами по себе решают проблемы бизнеса. Что купив, к примеру, ERP, предприятие уменьшит производственные запасы, а внедрив CRM сразу устранит риск увода клиентов лихими менеджерами.
Да, наличие рации необходимо для вызова железной птицы. Но вот для того, чтобы она действительно прилетела, нужно еще очень многое знать и о многом думать. Корни нашей проблемы находятся в нашем же прошлом. У руля предприятий стоят технари с технарским складом ума. Подавляющее большинство ИТ компаний тоже возглавляют технари. Технари верят в технику, в программы, в алгоритмы, в возможности систем. Технари с пренебрежением относятся к ”бумажкам”: регламентам и инструкциям. И уж совсем не верят технари в людей. А ведь люди это главный ресурс и главные средства производства ИТ-компаний. Люди — это основные шестеренки любых бизнес-процессов, независимо от уровня их автоматизации. Нельзя пренебрегать людьми в процессах и недооценивать их влияние на успех любого проекта. Те проекты, где понимают это, становятся украшением карьеры каждого участника команды.
Может быть, коллеги, я опять сказал какие-то банальности. Но я буду говорить банальности и очевидные вещи до тех пор, пока не канут в историю эти туземцы от бизнеса и их друзья-шаманы в деревянных наушниках.
P.S. от 23.09. Коллеги прислали ссылку на статью Михаила Плисса «Облом амбиций, или почему позиция CIO в России – карьерный тупик», которая прекрасно дополняет данный пост. Даже и добавить нечего. Читаю и почтительно молчу.
