Бизнес-процессы в нагрузку

    Многие знают о ”культе карго” — удивительном явлении, имевшим место во время Второй мировой войны. В ходе боевых действий удаленные острова в Тихом океане вдруг стали стратегическим объектом, американцы построили на них военную базу, и местные туземцы были осчастливлены продуктами цивилизации, которые доставляли грузовые самолеты. Туземцы решили, что хитрый белый человек, который сам не производит никаких материальных ценностей, получает их напрямую от богов, выполняя загадочные ритуалы: марширует с палками по плацу, сидит возле ящика с антенной и молится на непонятном языке, призывая небесных птиц. Когда война окончилась, американцы оставили острова и их наивных обитателей. Когда же позднее на остров вернулись исследователи, они с удивлением обнаружили туземцев с нарисованными нашивками, марширующих по плацу и шаманов, призывающих ”карго” в деревянных наушниках перед муляжом радиостанции.

    Культ карго, как оказалось, процветает не только на далеких островах, но и в кабинетах наших российских руководителей. Они уже много лет находятся в полной уверенности, что если надеть костюм, сесть в кресло, потратить деньги на дорогую импортную систему, то прилетят железные птицы и эффективность бизнеса автоматически повысится. Иногда на горизонте появляются также жрецы в деревянных наушниках с визитками различных консалтинговых компаний и оказывают посильную помощь в призвании железных птиц.

    Но отвлечемся, пожалуй, от лирических аллегорий и поговорим о том, как и почему в проектах внедрения АСУ разные люди делают одни и те же ошибки, связанные с пренебрежением элементарными вещами. А именно, почему же заказчики проектов отказываются видеть собственные бизнес-процессы.

    Начнем с наиболее вопиющего примера недальновидности заказчика, приведшего в итоге к суровому клинчу в проекте. Один государственный заказчик захотел систему управления сложным объектом. Он сформулировал подробные требования к функциям сбора данных и управления, к подсистемам, сформировал общие задачи на бизнес-уровне (”улучшение того-то”, ”уменьшение сего-то”), сформулировал требования к документированию, к надежности и еще много к чему в полном соответствии с ГОСТ 34Х.

    Исполнитель взял эти требования и начал разрабатывать систему. Ранний прототип не вызвал у заказчика никаких особых претензий, и исполнитель продолжил разработку. Все было просто и логично: на экране было изображение объекта управления. Пользователь следил за состоянием объекта, выбирал различные элементы системы и мог проделать с ними определенные действия. В строгом соответствии с техническим заданием.

    Самое интересное началось, когда заказчик начал думать об организации работ по эксплуатации объекта управления. Появились люди, которые стали задавать вопросы о том, как они должны будут работать, и кто что должен будет делать. Правильные вопросы, на которые у заказчика не было ответов. И он, руководствуясь очевидной для многих руководителей логикой, решил ”отжать” все, что необходимо для организации работ у разработчика, на свою беду не успевшего еще сдать систему и бежать с деньгами.

    Начал он с регламентов новой службы. Исполнитель со вздохом снял людей с внедрения и направил их на разработку регламентов. Ссориться с заказчиком ему не хотелось. Потом заказчик решил, что организационное взаимодействие между людьми дело дюже сложное, требующее автоматизации. А потом он вдруг подумал, что неплохо бы сделать так, чтобы разрабатываемая система могла поддерживать процессы взаимодействия и гибко под них адаптироваться. Но тут уже возобладали законы физики, и исполнитель начал поглядывать в сторону леса, заранее оплакивая съеденный аванс.

    Потому что, как оказалось, заказчику на самом деле нужна была автоматизация бизнес-процессов со всеми ее ”плюшками” — автоматической документацией, гибкой настройкой правил в графических редакторах, пользовательскими интерфейсами, которые создаются в реальном времени в зависимости от бизнес-правил… Исполнитель попробовал прикрыться ТЗ, но кого в наше время волнуют дурацкие бумажки? В итоге заказчик начал массированный троллинг, стал затягивать приемку работ, исполнитель столкнулся с финансовыми проблемами, сотрудники начали разбегаться, а проект оказался на грани закрытия. Успешный, между прочим, проект разработки АСУ.

    Второй пример более мягкий, но не менее показательный. Крупный коммерческий заказчик захотел систему управления некими процессами. Исполнитель взял специализированную платформу и начал разработку. В ходе обследования выяснилось, что на самом деле процессов у заказчика никаких нет, а есть некая неформализованная деятельность, местами носящая хаотический и судорожно-конвульсивный характер. А так как формализация и постановка бизнес-процессов в состав работ не входила, пришлось выкручиваться разработчикам системы. Они почесали затылки и решили реализовать самый простой с их точки зрения вариант процесса. Заказчик, у которого, напомним, формализованных процессов не было, тоже почесал в затылке и принял предложенную форму процесса.

    Веселье началось, когда сотрудники заказчика попробовали использовать систему. Оказалось, что процесс разработан неудобный, где-то слишком сложный, а где-то недостаточно детальный. Система, его реализующая, также оказалась совсем не той, что ожидал заказчик. Начался этап мучительной притирки, когда в ходе бесконечных торгов система стала приобретать требуемый вид, а заказчик начал выстраивать и описывать свои процессы. Сроки внедрения увеличились вдвое, затраты с обеих сторон также выросли до совершенно безобразных размеров. Проект заканчивали уже из чистого принципа, а после передачи очередного этапа почти вся измученная команда исполнителя уволилась.

    Третий пример будет примером успешным. Заказчик захотел систему автоматизации бизнес-процесса. Техническое задание содержало требования как к самому процессу, так и к системе его автоматизирующей. Перед началом проекта заказчик провел обучение ключевых пользователей и участников команды внедрения, на котором показал принципы организации проектируемого бизнес-процесса, его преимущества. Из всей массы пользователей выделились несколько энтузиастов, которые и составили основу команды внедрения со стороны заказчика.

    Две трети работ проекта были связаны с разработкой всяких инструкций, регламентов взаимодействия, матриц ответственности и тому подобного. Когда начались испытания системы, за компьютеры сели подготовленные и обученные пользователи. И хоть система оказалась достаточно скудной по функциональности, процесс стартовал сразу и без скрипа. Насколько мне известно, он успешно работает до сих пор (вот уже три с лишним года) безо всякого участия каких бы то ни было консультантов.

    Подведем итоги. Первый пример нам демонстрирует ошибку в оценке первоначальной потребности заказчика. Опытные внедренцы должны не только читать ТЗ, но и смотреть на бизнес заказчика. Если у него нет описанных процессов, если в его организации не сформированы еще отделы, в которых будут работать будущие пользователи, то это первый тревожный звоночек. Рано или поздно такой заказчик захочет организовать эксплуатацию. И если он не станет у вас покупать консалтинговые услуги по организации процессов (а это почти всегда так), то вам все равно нужно заложить в архитектуру системы возможности для гибкой подстройки процессов в ходе внедрения и даже в ходе эксплуатации. Например, вместо SCADA системы реализовать систему на базе ESB или их симбиоз. Для заказчика это будет более дорогое решение и по платформе и по дополнительным мощностям, но за гибкость нужно платить, а риск оказаться в итоге у разбитого корыта требует принятие мер.

    Второй случай демонстрирует нам проблему оторванности менеджмента от реальной ситуации. Заказывая вам систему, они искренне верят своим подчиненным, которые их уверяют в том, что все процессы уже давно описаны и ничего не нужно придумывать. Потом они признают свои ошибки, но вам-то от этого будет не легче. Рецепт тут тоже прост как три копейки. Спуститесь из офиса директора на производство. Посидите рядом с исполнителями, поговорите с ними как равный с равными. Они вам расскажут обо всех своих бедах — и что инструкций нет, и что бардак в управлении, и что в столовой мяса не докладывают. Послушайте их, да и включите в коммерческое предложение пункт ”актуализация бизнес-процессов”. Может быть, руководитель подумает, да и заплатит вам за эту работу. И это будут деньги, вложенные в правильное дело.

    При чем же тут культ ”карго”? А при том, что мы, словно те туземцы, еще не оправились от нахлынувшей на нас из-за исчезнувшего железного занавеса волны разнообразных ”лучших практик”, ”передовых методик” и чудодейственных систем. Многие верят в то, что системы сами по себе решают проблемы бизнеса. Что купив, к примеру, ERP, предприятие уменьшит производственные запасы, а внедрив CRM сразу устранит риск увода клиентов лихими менеджерами.

    Да, наличие рации необходимо для вызова железной птицы. Но вот для того, чтобы она действительно прилетела, нужно еще очень многое знать и о многом думать. Корни нашей проблемы находятся в нашем же прошлом. У руля предприятий стоят технари с технарским складом ума. Подавляющее большинство ИТ компаний тоже возглавляют технари. Технари верят в технику, в программы, в алгоритмы, в возможности систем. Технари с пренебрежением относятся к ”бумажкам”: регламентам и инструкциям. И уж совсем не верят технари в людей. А ведь люди это главный ресурс и главные средства производства ИТ-компаний. Люди — это основные шестеренки любых бизнес-процессов, независимо от уровня их автоматизации. Нельзя пренебрегать людьми в процессах и недооценивать их влияние на успех любого проекта. Те проекты, где понимают это, становятся украшением карьеры каждого участника команды.

    Может быть, коллеги, я опять сказал какие-то банальности. Но я буду говорить банальности и очевидные вещи до тех пор, пока не канут в историю эти туземцы от бизнеса и их друзья-шаманы в деревянных наушниках.

    P.S. от 23.09. Коллеги прислали ссылку на статью Михаила Плисса «Облом амбиций, или почему позиция CIO в России – карьерный тупик», которая прекрасно дополняет данный пост. Даже и добавить нечего. Читаю и почтительно молчу.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 33

      +7
      Проблема давно уже не в технарях. Бизнес-процессы те же алгоритмы, это понятно любому.
      Проблема в том, что у руля стоят люди с улицы — свояки, знакомые, родственники. Которые просто не готовы к руководящим постам.
        +1
        Происхождение руководства заказчика тема отдельная. Но тут уж или смирись или умри. Они платят деньги, а мы за эти деньги должны выполнить работу. Будь они хоть буратинами деревянными, в конце проекта они должны принять работу и выплатить остатки денег. А успех сдачи работ зависит от того, что мы заложим в проект и в архитектуру системы. В моих примерах виноваты, все же, исполнители. В первом случае они прозевали бизнес заказчика, а во втором переоценили самого заказчика.
          0
          У исполнителей тут дело скорее в том, что у них зачастую нет человека достаточно разбирающегося в предметной области, а консультанта нанимать жаба душит.
        +5
        Чем то напоминает мое начальство, которое любит говорить: «Вот тебе задача и срок в 8 часов, ты посмотри там, как немцы в SAPе предложили и расскажи нам, может подойдет». И потому мы уже который год до сих пор «с нарисованными нашивками маршируем по плацу и шаманим перед муляжом радиостанции».
          +1
          Классика :) В БД САПа около 70 тысяч основных таблиц, безумное количество транзакций, свои методики ведения проектов, построения архитектур… Нет, 8 часов мало, надо было давать все 16.
            0
            Вам 2,43 секунды на таблицу кажется мало? Вы прямо как непрофессионал.

            / сарказм /
          +5
          Нередко заказчик формулирует задание и таким образом: «хочу, чтобы было пиздато!».
            +5
            Ага. А иногда еще и таким: «Ну вы же специалисты — сами все знаете».
              +1
              Только вот в этом случае нужно готовиться к следующей фазе. «Не знаю как, но не так». Или просто «не нравиццо!!!»
              0
              и лучше чем у соседа…

              Ну и чтобы два раза не вставать.
              Культ карго у нас глубже, то есть выше, чем уровень принятия решений об автоматизации. Одни айфоныш с нанистом чего стоят. Но корни проблемы да — тотальный культ карго пока рулит, ему служить выгодно и популярно.
                +1
                И таки будет! Главное, чтобы заказчик это понял. Мне в этой связи вспоминается реплика персонажа из мультика «Тачки»: Ты не знешь, чего тебе нужно, Луиджи знает чего тебе нужно!
                  0
                  И, причем, "еще вчера"!
                  0
                  Сказано хорошо, но между своими. По-хорошему, это надо чуть переделать и давать всем заказчикам ДО подписания контракта. Тогда будет толк.
                    0
                    Контракты часто подписываются в бане, и не всегда возможно вклиниться в этот процесс. Лоббисту, конечно, дают материалы и наброски предложений. Но вот бывает, что после пятого стакана вискаря он забывает слова и путается в концепциях.
                      0
                      Типичные примеры того, что снятие задачи — ключевой этап в процессу автоматизации СУ. Опыт показывает, что изначально ни один заказчик — ни один! — не представляет себе задачу со всех необходимых сторон. И это нормально, а не признак тупости или некомпетентности.
                      Разработчик же в свою очередь обязан понимать риски и закладывать их в проект. Многих аналитиков/пээмов приходится принудительно приучать, что максимально ясное понимание и описание задачи нужно в первую очередь нам, а не заказчику, что чем больше бумаги, тем чище жопа, и в то же время одна лишь бумага не спасет сложный проект, если нет прямого налаженного контакта с ЛПРами. Это трюизмы, конечно, но реально многие люди при выходе в поля забывают об этих базовых вещах.
                        0
                        Да, опыт тут ценнее всего… Приведенные примеры, кстати, касались первых внедрений новых для нашей страны систем. Внутри опыта не было ни у кого, отсюда и такие фактурные грабли.
                        Когда внедряется что-то более привычное, нужно опираться на опыт свой или коллег. Обязательно.
                          0
                          Думаю, что и не только новые системы (достаточно курпные) до сих пор внедряются аналогично. Исключения, как мне кажется, очень редки. Даже зачастую проекты, кажущиеся снаружи успешными, на самом деле успешны очень недолго, один-два года… пока не ушли энтузиасты их постоянно «поддерживающие». Именно «поддерживающие», а не сопровождающие.
                            0
                            Да, вы правы. Вопрос жизнеспособности систем достаточно тонкий и требующий дополнительного изучения. У меня есть мысль написать об этом, но пока никак не нащупаю идею.
                        0
                        Скажите, что нужно сделать, чтобы научиться распознавать такие ситуации?
                        Эти все проекты прошли через вас?
                          0
                          Основные общие признаки даны в выводах. Детально можно писать только о конкретных проектах, а не вообще.
                          Если повторяться, то нужно подумать, чего же именно хочет заказчик. Буквально сегодня читал очень хороший материал на эту тему habrahabr.ru/blogs/pm/128786/

                          Все примеры из личного опыта. Единственное, не нужно пытать меня что были за организации с той и с другой стороны. Я сознательно перемешал и утрировал некоторые признаки, чтобы не было причин упрекнуть меня в нарушении корпоративной этики.
                            0
                            Чтобы распознавать такие ситуации, достаточно иметь грамотного аналитика и/или архитектора. Тогда они уже на первых этапах стали бы задавать неудобные вопросы заказчику. А это повлекло бы пересмотр ТЗ, рисков, затрат и сроков.
                              0
                              Иногда, для того, чтобы стать грамотным аналитиком, нужно наступать на грабли. Каждая компания желает купить готовенького, желательно ясновидящего, аналитика. И не задорого. И мало кто хочет такого выращивать, неся убытки :)
                                +1
                                Как это ни прискорбно, но наступать на грабли это основное занятие аналитиков.

                                Не помню где читал, но есть такой посыл: нельзя поручать ответственный проект человеку, для которого этот проект будет вторым в его карьере. Он постарается исправить абсолютно все ошибки, которые он допустил в первом проекте и никогда его не закончит, потому что будет пытаться сделать все идеально.

                                На мой взгляд лучше у аналитика спрашивать какие проекты он провалил (или закончил с очень большим скрипом) и какие уроки он из этого извлек, нежели спрашивать про успешные проекты. Потому что это покажет не то, как ему везет с заказчиком, а насколько адекватно он может оценивать свои ошибки или ошибки заказчика.
                                  0
                                  Эх, как хорошо мы тут друг другу поем! Такие слова, да начальству в уста :)
                                    0
                                    Так надо самому и становиться начальством. Все в наших руках =)
                                      0
                                      Нет, ТАКИМ начальством в России не стать. Не с теми в детсад ходил. И не тем видом спорта не в том городе занимался :)
                                        0
                                        Зря вы так. Если есть желание и голова на плечах, то сейчас можно достаточно быстро подняться по карьерной лестнице в ИТ команде, при этом сохранив свое достоинство (не расталкивая друзей локтями).
                            0
                            Как-то камментов по теме бизнес-процессов на хабре совсем мало.
                            Все всем понятно, иди тема не так актуальна (интересна)?

                            Вообще интересно было бы почитать подобные структурированные труды, чтобы поучиться новому ремеслу для себя :)
                              0
                              На Хабре много программистов, у которых вполне конкретный опыт и большой спрос на него. В части же бизнес-процессов не все так однозначно, и примеры кода не опубликуешь. И народ в основном зрелый, на ерунду размениваться не желающий.
                              Вот и приходится им вариться в вакууме, преисполняясь ощущением собственного величия.

                              А «структурированных трудов» на тему много написано, хоть обчитайся. Беда только в том, что западные книжки написаны в расчете на людей, имеющих небольшое представление о классическом менеджменте. А у нас в эту область влезают в основном программисты, которые ничего не видят, кроме алгоритмов и программ…
                                0
                                А что вы понимаете под «классическим менеджментом»? Это я для того, чтобы сравнить понятия у вас и у меня, ввязавшись в дискуссию. :)
                                Потому как я вижу немного обратную ситуацию, пройдя некоторую ступень эволюции (так же быв программистом), увидел что действительно, большинство бизнес-аналитиков, внедренцев и пр людей причастных к построению бизнес-процессов в компаниях бывшие ИТишники. Будь то они программистами, сисадминами или еще кем-то. И они перкрасно понимают где алгоритмы, а где менеджмент.
                                Сфера, в которой мне больше приходится сталкиваться — различные сферы услуг, без пр-ва какого-то товара. А у вас, судя по тексту как раз наоборот — пр-во в полный рост. Возможно в этом проблема? ИТишники не хотят идти в пр-во, т.к. «с рождения» не производили товары?
                                  0
                                  У меня нет законченного второго образования в области управления, но мне приходилось и учиться на специальных курсах и управлять людьми, а также лично ставить процессы. Я много лет работал на
                                  Классический менеджмент — это как минимум что-то в рамках элементарного учебника:
                                  — как ставить задачи и контролировать исполнение
                                  — основы мотивации
                                  — проблемы во взаимодействии

                                  Без знания подобных вещей трудно спроектировать бизнес-процесс. Это ведь не квадратики в программе рисовать, как может показаться. Это в первую голову организация взаимодействия людей. Программы тут только на втором плане.
                              0
                              Полезная статья и написана очень хорошо — интересно читать, хоть и много текста. Автор, пишите еще.
                                0
                                Рад стараться!

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое