Расскажу, как правильно подготовиться к проекту автоматизации, какую роль на этапе подготовки играет моделирование бизнес-процессов и с какими типичными ошибками можно столкнуться в ходе моделирования.
На этапе подготовки к внедрению мы должны…
-
Выявить бизнес-цели автоматизации
Когда на старте проекта автоматизации заказчику задают вопрос: «Какая у вас цель внедрения?», он чаще всего отвечает: «Нужно навести порядок в учете».
Причем реальная цель зачастую – увеличить продажи на 20%, но заказчик считает, что сейчас этого достичь невозможно, потому что у него нет CRM. Он уверен: как только CRM появится, продажи сразу увеличатся. Система сама решит его проблемы, фактически заменив управление. И хотя у него уже есть текущая система, он считает, что нужна более современная, тогда все станет хорошо.
Чтобы разобраться, нужна ли в действительности заказчику новая система, мы задаем ему вопросы, пока не дойдем до сути. По аналогии с техникой «Пять почему» мы используем технику «Пять зачем».
-
Например, на вопрос: «Какая у вас цель внедрения?» заказчик отвечает: «Внедрить ERP». Получается, что проект нужен ради самого внедрения, а это звучит странно.
-
Поэтому мы уточняем: «А зачем вам ERP?» – «Потому что поддержка УПП скоро закончится». Но кроме внедрения ERP есть куча вариантов, как можно еще решить эту проблему.
-
Задаем следующий вопрос: «Почему именно ERP?» – и тут возможны разные ответы: «Потому что все внедряют ERP», «А что еще можно внедрить?» Или даже «Вы что, сами не знаете, для чего 1С нужна, что ли?»
Если заказчик сам не понимает свою бизнес-цель, ему нужно помочь ее сформулировать, и дальше уже декомпозировать эту бизнес-цель до конкретных задач.
-
Заказчик должен понять, чего конкретно он хочет от информационной системы (задачи). В том числе, какие проблемы планируется решить в результате проекта внедрения.
Например, заказчик должен понять, что в системе не будет большой волшебной кнопки, по нажатию которой данные в программе появятся сами. Более того, после внедрения новой системы трудоемкость процессов обычно не особо снизится, и чаще даже возрастет. В этих вопросах заказчика нужно приземлять.
Это нужно объяснить не только бизнес-заказчику (руководителю компании), но и всем функциональным заказчикам, с которыми вы будете общаться. Необходимо с каждым из них проговаривать, какие задачи будут реализованы, а какие – не будут. Или какие задачи можно реализовать только за очень дорого.
Очень правильно, когда аналитик в этот момент спорит с заказчиком, убеждая его, что это автоматизировать не нужно, развенчивает «уникальные идеи», приводя в пример опыт множества других проектов.
Пример из практики: на одном крупном производственном предприятии главный конструктор предлагал разработать систему для хранения кода управляющих программ, которая при нажатии кнопки «сохранить» мгновенно отправляла бы сформированные команды на станок с ЧПУ. Аналитик объяснил, что такой механизм без предварительной проверки может привести к хаосу в работе. В итоге заказчик согласился.
-
Понять точку старта.
Считается, что понимание бизнес-процессов «как есть» нужно только исполнителю. Заказчик и так все понимает. И деньги, которые берет исполнитель за предпроектное обследование, являются платой за погружение специалистов исполнителя в контекст, а самому клиенту никакой ценности не несут.
Однако большинство компаний работают не так, как написано в регламентах. И если спросить сотрудника, его руководителя и генерального директора про работу одного и того же бизнес-процесса, все трое дадут абсолютно разные ответы. Потому что все это видят по-разному.
Поэтому важно, чтобы не только исполнитель понял точку старта – нужно, чтобы точку старта поняли все.
-
Провести ревизию и договориться, что нет смысла переносить все, что есть
Мы уже привыкли, что для переноса данных со старого телефона на новый достаточно просто положить их рядом на полчаса. После чего на новое устройство перенесутся все старые программы, иконки расположатся на тех же местах, а заставкой станет фотография любимого котика пятилетней давности, когда он еще котенком был. При этом в новом телефоне будет лучше камера, ярче экран, новый аккумулятор и работать все будет гораздо быстрее.
Когда происходит переход с одной программы на другую, заказчики тоже хотят, чтобы в новой системе был доступ ко всем данным, которые накоплены в компании за предыдущие десятилетия. Чтобы там было все то же самое, что и в старой: самописные функции, привычные интерфейсы. Это все очень нужно. Без этого вся работа встанет.
Я знаю случай, когда заказчик потратил на проект перехода 1С:ERP несколько сотен миллионов рублей, а потом через год запускал отдельный проект, чтобы ему объяснили, как в 1С:ERP считается себестоимость, потому что хотел, чтобы результаты расчетов полностью совпали с результатами в предыдущей системе.
Лучше сразу приземлить ожидания заказчика и убедить его не переносить данные в новую систему. Этим мы сэкономим кучу его денег. И времени его сотрудников.
-
Заказчик должен быть готов к неизбежным организационным изменениям
Любое крупное внедрение – это большая боль для всех. В первую очередь, это проект организационных изменений, а уже во вторую – проект автоматизации. Заказчики действительно могут надеяться, что новая система заменит им регулярный менеджмент. Но эти надежды чаще всего неоправданны.
У нас был случай, когда во время обследования у заказчика мы столкнулись с проблемой: они формировали производственный план с расчетом, что времени на выполнение всех заказов хватит. Однако по итогам месяца каждый раз оказывалось, что несколько заказов не были выполнены в срок. Изначально на каждый заказ закладывался достаточный запас по срокам, но сроки все равно срывались.
Начали разбираться, как они планируют. Выяснилось, что они формировали планы по каждому цеху в начале месяца. И рабочие, у которых была сдельная оплата труда, выбирали себе из этой стопки самые оплачиваемые заказы. В первую очередь делали их, а остальное уже в конце месяца. Из-за этого сроки срывались.
Как тут поступить? С одной стороны, можно внедрить систему, которая будет выдавать задания по одному, исключая выбор. С другой стороны, люди привыкли так работать и последствия могут быть негативными, вплоть до забастовки.
Желательно такие моменты выявить заранее, решить их через организационные изменения, и только потом запускать автоматизацию.
-
Найти функциональных лидеров на проект
При запуске проекта автоматизации нам нужны функциональные лидеры из числа сотрудников заказчика. Обычно на эту роль назначают тех, кто посвободнее, либо тех, у кого компьютер есть, либо вообще все на ИТ-ишников скидывают.
В итоге у таких принудительных назначенцев нет особой мотивации.
Но всегда, в любой компании есть люди, которые заинтересованы в улучшениях. Их нужно выявлять еще до старта. Они должны стать той движущей силой, которая будет двигать этот проект вперед.
-
Договориться о реалистичной детализации учета
Еще одна из частых причин проектов автоматизации – недостаточная детализация данных в текущей системе, что приводит к другой крайности: при переходе на новую систему появляется желание учитывать абсолютно все, вплоть до каждого болтика.
Однако даже самая крутая система сама по себе не решит эту задачу. Для ее работы потребуется:
-
Сотрудник, который будет вводить данные – а ему на это нужно время.
-
И сами данные, которые должны быть достоверными, объективными, полными, качественными, понятными, своевременными.
Нужно помнить, что детализация – это всегда дополнительные затраты. Нам либо более точные и дорогие весы нужны, либо люди нужны, чтобы эти данные вводить. Поэтому нужно всегда заранее оценивать, какие затраты потребуются на детальный учет, и какие выгоды он принесет.
-
Пройти вместе с заказчиком 5 стадий принятия
Внедрение – это всегда большой стресс для сотрудников заказчика. Их можно понять – жизнь у них поменяется, но они до конца не понимают, как именно. Поэтому они неизбежно сопротивляются, проходя через все стадии: отрицание, гнев, торг, депрессия, принятие.
Правильная подготовка помогает нам пройти все эти стадии вместе с заказчиком.
Например, моделирование процессов «как будет» мы проводим совместно с заказчиком. Когда заказчик является соавтором, он работает для себя. Он понимает, как система будет работать, принимает это, и в дальнейшем сопротивления будет меньше.
-
Выработать у заказчика готовность и привычку выделять ресурсы на проект
Желательно, чтобы заказчик заранее научился выделять ресурсы. Если на этапе подготовки вам постоянно что-то не дают, не успевают, решения принимаются в последний момент и нормально не прорабатываются, в проекте будет то же самое.
Лучше заранее понять, каких ресурсов не хватает. Например, можно временно нанять дополнительных людей или приставить к ключевым функциональным заказчикам помощников. Эти вопросы нужно решить именно до старта.
-
Сформировать дорожную карту проекта
Большой проект невозможно реализовать за один шаг – его необходимо разбивать на несколько этапов.
Важно заранее спланировать, какой результат мы получим на каждом этапе:
-
С одной стороны, каждый этап должен представлять собой самостоятельную ценность для заказчика.
-
С другой стороны, промежуточные результаты должны последовательно приближать нас к большой цели всего проекта.
Это тоже нужно понимать при подготовке.
-
Разобраться, нужно ли продолжать проект
Бывают ситуации, когда после этапа подготовки продолжение проекта оказывается нецелесообразным.
-
Одна из причин – постоянное недопонимание между заказчиком и исполнителем, различия в корпоративной культуре и подходах к работе. Если стороны изначально друг другу не подходят, гораздо выгоднее, дешевле и для заказчика, и для исполнителя понять это заранее на небольшом предпроекте, чем вписаться в большую автоматизацию и где-нибудь на этапе опытно-промышленной эксплуатации понять, что у вас проблемы. Это обойдется всем намного дороже.
-
Еще одна причина, почему исполнитель может передумать участвовать в проекте дальше – изменение требований. Например, изначально заказчик планировал внедрять одну систему, но в процессе понял, что ему нужна совсем другая. Потому что у проблемы «поддержка УПП заканчивается» есть не только решение «внедрить ERP», но и много других решений, одно из которых подошло заказчику больше.
-
Кроме того, уже на этапе подготовки к проекту может выясниться, что сначала нужно провести организационные изменения и только после этого приступать к автоматизации. В этом случае автоматизацию стоит поставить на паузу, переключиться на другие проекты и вернуться к этому уже потом.
В таблице перечислены все наши ожидания от подготовки к внедрению. Галочки здесь – это степень влияния проработки каждого из ожиданий на:
-
результат составления ТЗ;
-
моделирование бизнес-процессов;
-
и формирование дорожной карты.
Результат выглядит так, как будто я агитирую при подготовке как можно детальнее прорабатывать бизнес-процессы. Но по моему мнению моделирование бизнес-процессов – это действительно самый эффективный инструмент подготовки заказчика к тому, чтобы проект автоматизации стал для него более понятным, осознанным, управляемым и имел больше шансов на успех.
Типичные ошибки моделирования бизнес-процессов
Однако, если провести моделирование неправильно – это может принести проекту больше вреда, чем пользы. Поэтому расскажу про типичные ошибки, которых важно избежать в ходе моделирования.
-
Начинать работу без соглашения о моделировании и регламента взаимодействия
В первую очередь, начинать работу нужно с составления соглашения о моделировании и с регламента взаимодействия, в которых будет описано: в какой нотации описываем, как сдаем работы, как проходит согласование и так далее.
Иначе при принятии отчета об предварительном обследовании особо дотошный сотрудник заказчика станет предъявлять претензии, что у схем цвета не те, у названий действий форма глагола не та, и т.д. Придется на все претензии отвечать, обстоятельно доказывать, спорить или переписывать всю модель.
Если же есть соглашение, на подобные претензии можно ответить, сославшись на документ, где заранее описаны все договоренности по моделированию.
-
Слишком детальное описание
Часто заказчики просят расписать процесс как можно детальнее, вплоть до того, что не имеет отношения к работе в программе. Например, в процессе приемки денег в кассу не нужно описывать, что кассир должен взять деньги, проверить каждую купюру на подлинность и так далее. В контексте наших целей это не имеет никакой ценности, а на такую детальность уходит много времени и согласований.
-
Надеяться на анкетирование
Часто в ходе предварительного обследования заказчика просят заполнить анкеты. Но если вы рассчитываете, что именно в ходе моделирования подобные анкеты помогут, вас ждет разочарование.
Сначала вашу анкету будут перекидывать как горячую картошку туда-сюда, По статистике:
-
если у вас в анкете будет 5 вопросов, на них ответят примерно 60% респондентов;
-
если в анкете будет 105 вопросов, то на них никто не ответит;
-
а если у вас будет 20 вопросов, то на них часть респондентов не ответит, часть – частично заполнят, а оставшиеся – в последние 15 минут перед дедлайном что-то быстренько напишут и отправят.
Поэтому для моделирования необходимо проводить именно очное интервью, познакомиться со всеми людьми лично и обменяться телефонами. В этом случае сотрудники с бОльшей готовностью будут отвечать на ваши вопросы и в дальнейшем с вами взаимодействовать – вы уже не будете для них «говорящей головой» в телевизоре, они будут вас воспринимать как живого человека.
-
Слабая базовая подготовка консультантов 1С в предметной области
Многие консультанты 1С отлично разбираются в программе, но плохо представляют себе предметную область.
Когда такой специалист приходит на производство и начинает задавать, с точки зрения производственников, глупые вопросы, это сразу снижает доверие. Если он теряется при словах «гальваника» или «ЛЗК», отношение к нему становится, как минимум, снисходительным, а иногда и откровенно предвзятым – как к нему самому, так и к его работе, и к компании, которая его отправила.
Такой консультант не может корректно описать процессы, которых действительно не понимает, потому что производство – это не только то, что в 1С, оно гораздо шире. Поэтому посылайте на производство аналитиков и не посылайте консультантов.
-
Долго делать модель
Успех моделирования напрямую зависит от степени вовлеченности людей.
Но высокую концентрацию у сотрудников поддерживать на длительном периоде нельзя. Потом люди устанут, начнут прокрастинировать, будут откладывать погружение в задачу на последний момент.
Если на предприятии 100-120 процессов, то на рисование схем, интервью, согласования, детали и уточнения потребуется 10-11 недель. В этот срок желательно укладываться.
-
Использование бесплатных или непрофессиональных инструментов для моделирования
Вы, наверно, не захотите, чтобы вас в парикмахерской стригли канцелярскими ножницами? Так и тут: если человек говорит, что готов делать модель в чем угодно, хоть в Word – это 100%-й любитель.
Непрофессиональное программное обеспечение имеет кучу ограничений и не позволяет создать нормальную цельную модель, а на ее создание уходит больше времени. Это сразу выдает непрофессиональный подход к делу
-
Плохая читаемость схем
Схема бизнес-процесса, которую мы создаем, должна быть читаемой. Ее нельзя делать бесконечной, потому что она всегда будет распечатываться – даже если вы привыкли работать со схемой на экране, большинство людей все равно будут схему распечатывать.
Кроме того, важно учитывать степень подготовки у разных людей: если генеральный директор, возможно, легко разберется в схеме, то кладовщик – вряд ли.
Перефразируя Генри Форда, который говорил: «Цвет автомобиля может быть любым, если он черный», в нашем случае: BPMN может быть любым, если он вертикальный.
Горизонтальный BPMN, на мой взгляд – это зло. Мало того, что на мониторе приходится постоянно перемещаться по схеме вправо-влево, а если дорожек чуть больше, то еще и вверх-вниз. Такое мельтешение абсолютно сбивает с толку.
И в печатном варианте горизонтальный BPMN для работы неудобен.
-
Разработка под типовые решения 1С
Существует классическая дилемма: либо мы программу затачиваем под процессы компании, либо компанию под программу.
Если внедренец знает только типовые возможности и боится брать на себя ответственность за доработки программы, у него всегда будет перекос во второй вариант, он всегда будет пытаться перевести заказчика на типовую систему, даже если это не оправдано.
-
Только третий уровень процессов
Еще одна частая ошибка – когда рисуют только третий уровень процессов. В большинстве случаев это связано с тем, что используются бесплатные инструменты, в которых полноценную модель не собрать.
Потому что третий уровень – это детальное описание процесса в какой-то нотации. А в типичной компании может быть до 100-120 процессов.
Если представить, что один процесс – это деталь пазла, то всю картину мы поймем только тогда, когда соберем все пазлы. Оценить в ней пробелы можно только в выстраивании полноценной трехуровневой модели.
В верхнем уровне, например, выберем процесс обеспечения работоспособности оборудования.
Во втором уровне декомпозируем выбранный процесс до подпроцессов.
Потом уже рисуем третий уровень, понимая его место в общей структуре.
-
Не проводится моделирование «как есть»
Как я уже упоминал, заказчики часто считают, что моделирование «как есть» – это зря выброшенные деньги. Но это не так. Любой проект – это переход из точки А в точку Б. Если я хочу пробежать марафон, но не знаю своей текущей физической формы, я не могу составить адекватную программу тренировок.
Точно так же и в проекте: мы хотим достичь определенной цели, но мы не знаем, где находимся сейчас. Мы не понимаем ни одного из трех основных параметров проекта – ни объем, ни бюджет, ни сроки. Мы не сможем их адекватно оценить.
Поэтому моделирование «как есть», на мой взгляд, нужно делать всегда.
-
Стремление строго следовать нотации
С одной стороны, нотации написаны умными людьми и согласованы в международных сообществах.
С другой стороны, мы проводим моделирование под конкретную цель, поэтому можно отходить от строгого следования нотации в пользу повышения понятности и читаемости.
Как правило, мы работаем с неподготовленными людьми, не специалистами в процессах, в организациях, где абсолютно разный уровень подготовки. Поэтому мы в своей работе используем несколько нотаций и при необходимости вносим в них свои изменения, которые, конечно, обязательно отражаются в соглашении о моделировании и согласовываются с заказчиками заранее.
Вопросы и ответы
Вы обозначили такое сочетание требований к моделированию процессов, как с одной стороны вертикальной BPMN, с другой стороны, возможность вложенности процессов, при этом не строгое следование нотации. Подскажите, в каком инструменте вы это делаете?
Мы это делаем либо в ARIS, либо в Business Studio. Но все рекомендации – на любителя.
На мой взгляд, горизонтальный BPMN – это плохо. Можно рисовать BPMN вертикально, можно в eEPC рисовать, можно в IDEF0 рисовать – тут уже как кому нравится.
По нашей практике, более понятны схемы бизнес-процессов в нотации eEPC.
И да, мы считаем, что можно отойти от строгого следования нотации eEPC и некоторые вещи в ней убрать.
Насколько я помню, ARIS не позволяет гибко добавлять элементы в свою нотацию. Вы просто используете какие-то части элементов не по назначению и фиксируете это в соглашении о моделировании? Правильно я понял?
Организационно – да, в соглашении все фиксируется. Но иногда заказчик настаивает: «Я хочу строго по классике eEPC» – без проблем. Или говорит: «Хочу в BPMN” – тоже без проблем.
Насколько эта технология применима при развитии уже внедренного решения?
Технология, о которой я рассказывал, в основном, заточена под переход на новую систему. А в довнедрении могут быть разные технологии. Какие-то элементы можно применять, но в целом задачи абсолютно разные.
Вопрос скорее о том, какие инструменты от большого внедрения могут нам помочь в довнедрении?
Например, желательно, чтобы задачу с клиента на проекте снимал аналитик, а не консультант, который знает только систему, но в производстве ни разу не был.
Для каких целей вы составляете схемы «как есть»?
Самая главная цель – понять, где мы сейчас, чтобы заказчик адекватно понимал, что у него в компании происходит, как это на самом деле работает. Часто генеральный спорит, думая, что компания не так работает. А в жизни оказалось, что они давно уже работают не так. Соответственно, требования могут быть абсолютно другие.
Но требования же формируются к новым процессам, а не к старым.
Да, но нам, чтобы понять, как нам перейти в светлое будущее, нужно понимать, где мы сейчас. Иначе – как мы составим этот путь? Как мы поймем, какой проект нам нужен, какой объем проекта должен быть, каким у проекта должен быть бюджет, если мы не понимаем, какой путь нам нужно пройти?
Получается, что если вы применяете такой подход, у вас есть поэтапный переход от старых процессов к новым? Просто процесс в моем понимании меняется один раз. Либо, если нужно, выстраивается некая лестница, когда несколько раз видоизменяется. Мы вроде как собрали требования, сформировали новый процесс и внедряем сразу новый процесс с нуля, а не делаем какие-то промежуточные этапы.
Иногда невозможно в один этап перескочить из одного процесса в другой из-за разных ограничений. Например, когда в новом процессе требуется больше детализации, у нас есть организационное ограничение – люди не готовы столько данных вручную вводить, у них куча другой работы. Нужно сначала их освободить, а потом нагрузить снова, но уже другими задачами. Мы не должны резко вводить детализацию, а должны делать это постепенно.
Кажется, что рисование процессов «как есть» очень удорожает проект.
Конечно, в какой-то степени удорожает. Проще сразу рисовать «как будет». Но на мой взгляд, это оправданно. Как минимум, за счет единого понимания с заказчиком. Потому что это очень важно. В большинстве проектов, которые мы делали, нужно было синхронизировать понимание о том, как работает компания, у всех участников проекта. Это важно, потому что у бизнес-заказчика ожидания формируются, исходя из понимания текущей ситуации.
Но у вас же нет технологии перехода от различных вариантов начальной точки в желаемую? Кажется, что начальная точка, где мы находимся, не важна. Не имеет значения, из какой точки мы идем, потому что технология перехода на новую систему от этого измениться не может.
Количество этапов может поменяться, сроки могут поменяться.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
