Начать придется с эпического фЭйла, когда пришел функциональным архитектором в крупную металлургическую компанию на проект внедрения ERP и получил в качестве системы управления проектом файл MS Project c датой начала проекта и датой внедрения. При запрещенных каких-ли облачных сервисах (безопасность) пришлось вертеться. Уже много позже "карманная" конфигурация 1С, в которой создавал отдельные списки объектов, превратилась в довольно логичную и простую "коробочную" конфигурацию, в которой работает моя проектная команда с несколькими проектами одновременно.
Что такое ERP-Tools
Чтобы построить высокое здание, требуется сначала поставить башенный кран и получить проект дома. ERT-Tools это кран и проект строительства одновременно. Как это работает:
- Приобретаете конфигурацию и устанавливаете на внутреннем сервере.
- Программа содержит 2 взаимосвязанных раздела "Функциональное моделирование" и "Сервис-деск". Эти инструменты на 95% обеспечивают накопление информации и обмен внутри проектной команды.
- Получаете работоспособную технологию выполнения проекта, следуя которой, вы четко идете к передаче проекта в эксплуатацию.
- Не нравится команда, РП или архитектор - поменяйте без рисков для проекта в целом. При соблюдении проектной технологии риски потерь ключевого сотрудника "который все знает" крайне низкий.
- Тестируете итоговую функциональность и запускаете в эксплуатацию.
- После начала эксплуатации продолжаете развивать учетную систему с помощью ERP-Tools
Опишу традиционный кейс внедрения ERP, которым и сам пользовался, пока не понял, что база данных сильно лучше файлов.
Традиционная технология и инструменты
- Найти на рынке Руководителя проектов, который почему-то свободен. Услышать от него, как он где-то что-то внедрял, не всегда удачно, так как кругом были враги.
- Найти аналитиков, которые почему-то свободны. Поверить, что все они знают, что делать.
- Собрать функциональные требования на интервью - MS Excel с перечнем ФТ.
- Понять, что совместно работать с единым файлом невозможно - перенести файл на Google tab.
- Попробовать реализовать ФТ штатными средствами, а в случае неудачи - зарегистрировать функциональный разрыв.
- Понять, что Google tab не удобен для работы даже 2 человек. Найти канбан-доску на облачных сайтах. Помещать туда только ФТ с признаком Разрыв.
- Создать Техническое задание - MS WORD. На всякий случай аналитик запустит его через почту в адрес всей команды. Кто-то подправит ТЗ и также его запустит в почту. Теперь крайняя версия ТЗ существует исключительно в почте. Ежедневно все члены проектной команды получают десятки писем, не совсем понятных, для кого они предназначены в первую очередь.
- Согласовать ТЗ - Почта, чаты.
- Выполнить разработку по ТЗ.
- Установить статус "Выполнено" у функционального требования в Google tab.
- На вопрос о степень готовности проекта - показать таблицу с перечнем реализованных ФТ и резюмировать: "Почти готово. Но кое-что еще нужно править".
В результате, как правило, получается "файлопомойка" с единственным актуальным файлом с перечнем ФТ и набором файлов разной степени актуальности.
Преимущества:
- Любой человек может стать руководителем проекта, главное - быть администратором файла с ФТ, участвовать в 100% обсуждений, замыкать все на себя.
- Аналитик любого уровня компетенции может делать проект в том стиле, котором хочет - главное, чтобы заносил в файл с ФТ ее текущий статус.
- Любой провал можно объяснить общим бардаком в компании.
Недостатки
- Надо договориться о совместном использовании файлов, чтобы 2 аналитика одновременно не входили в файл Excel или не ставили фильтры в Google таблицах.
- Как именно работает система - не совсем понятно. Функциональное требование само по себе не говорит о том, в каком процессе оно участвует. Это вырванное из контекста (бизнес-процесса) поведение системы.
- Критически важно удерживать членов команды, чтобы не потерять контекст. Уйдет РП - проект можно закрывать.
- Команда может работать с файлами разных версий, выполнять задачи, которые никому не нужны. Часто фиксируются только ФТ с признаком разрыва и по факту весь проект это "перечень нештатных доработок" без какого-либо взгляда "сверху".
- Архитектор должен быть в контексте всех задач всех аналитиков, так как это единственное связывающее звено. Архитектор должен делать вид, что все помнит и знает. Уходить в отпуск архитектору нельзя.
- Нормальный пакет инструкций по ERP-проекту может достигать 1000 страниц. Найти нужную в сотнях файлов практически невозможно. Поэтому большинство инструкций делается "для галочки", так как ее все равно никто не прочитает. Пользователь запросил инструкции по какому-то действию? Пусть получит ее в виде скрина прямо в письме.
- "Процессная" методика внедрения с использованием MS Office или облачных "канбан" систем нереализуема на практике
А теперь то, что работает на практике на сложных проектах с сотней рабочих мест с рабочими группами от 10 человек.
ERP-tools технология
0 шаг. Выбрать методологию и практику ведения проекта. AGILE - это не методология - это способ работы с плоским перечнем задач. Найти РП, который согласен придерживаться данной технологии. Найти и обучить команду стандарту. Ознакомить с технологией команду заказчиков.
Основным объектами внимания являются:
Процедуры - функции - инструкции - функциональные требования - объекты метаданных.
Тут я в явном виде перечисляю, а не скрываю общие термином "отдельные моменты проекты". Вот эти 5 объектов являются центровыми, вокруг которых и строится технология.
- Выявить Процедуры - существующие бизнес-процессы заказчика (Например, "Продажа клиенту")
- Определить шаги выполнения процедур - Функции (создать заказ, выставить счет, получить оплату, Отгрузить товар). Отдельная функция - это единичное действие с объектом метаданных системы - справочниками и документам.
- Начать моделирование системы, создавая Инструкции по каждой функции, получая инструкцию по Процедуре в целом.
- В ходе написания инструкции задавать вопрос - является ли текущее действие "функциональным требованием". Если да, то регистрировать Функциональное требование ("Отгружать только по предоплате","отгружать одним документом с 2 складов"). ФТ это не функция - это особенность выполнения отдельного шага функции, о котором в явном виде нужно спросить у бизнес-пользователя.
- Показать инструкции заказчику, согласовать все выявленные ФТ, получить дополнительные требования. Часто это ФТ с признаком Разрыв ("Хочу такое же, но с перламутровыми пуговицами")
- Подготовить "дизайн" преодоления разрыва (пользовательская история), согласовать с заказчиком, писать подробное ТЗ.
- Передать ТЗ на оценку архитектору, потом на реализацию программисту. По итогам проверки - создать Протокол доработки. На этом этапе в ERP-Tools используются Заявки и канбан-доски с типом "поручение".
- Контролировать выполнение текущих поручения от коллег/коллегами с помощью Канбан досок. Комментировать выполнение задач.
- Внести изменение в действующую инструкцию, показать обновленную инструкцию заказчику.
- Если заказчик удовлетворен выполнением функции - установить у нее соответствующий статус
- Если у процедуры все функции достигли высшего статуса ("заказчик удовлетворен"), значит вся процедура полностью удовлетворяет заказчика.
- Готовность проекта к эксплуатации достигается при 100% готовности всех Процедур.
Все эти действия происходят внутри ERP-Tools без использования MS Office, обеспечивая скорость выполнения проекта и его качество.
Результатом является четкий бизнес-процесс, по которому должны пройти 1 тысяча функциональных требований, 10% из которых в среднем является функциональным разрывом. Количество описанных "бизнес-процессов" достигает 100 и более, описываются порядка 500 функций по учету действий над более 100 объектов системы - отдельных справочников и документов.
Заказчик получается полностью документированную базу данных обо всех измененных Объектах Метаданных, с актуальными ТЗ, протоколами, и исчерпывающими инструкциями, подтверждающими, что команда действительно выполняет проект.
Преимущества:
- Четкий бизнес-процесс для аналитиков
- Возможность работы действительно большой команды - десятки аналитиков имеют 100% доступ к нужной информации, визуализируют ее так, как им нужно в этот момент, не мешают друг-другу, используют инструкции коллег.
- Функциональный архитектор не должен быть погружен в сотни разработок, делегируя функции контроля базе данных.
- Аналитик отвечает за блок, а архитектор отвечает за аналитика и его качество работы.
- Заказчик четко видит результат - от первичного ТЗ до инструкции. Становится понятен процент реализованных ФТ, процедур.
- База данных хранит все вмешательства в конфигурацию с указанием скорректированных объектов, причин, инициаторов, нового поведения системы (протоколы испытаний).
- Полная и всегда актуальная wiki для будущих пользователей системы, где они могут посмотреть - как должна выполняться отдельная операция. Нет нужной операции - Аналитик должен зарегистрировать Процедуру, определить шаги-функции, написать инструкции.
- Выполнив 100% ФТ, произведя обучение по 100% процедур скорее всего достигается целевая архитектура.
- Статус готовности проекта всегда виден - смотрите готовность Процедур.
Недостатки
- Нужно выполнять четкий процесс, а часто этого не хочется делать, например, поставив ТЗ в чате программисту или даже позвонив по телефону.
- Аналитик, архитектор и даже РП перестает быть критически значимым сотрудником.
Почему Канбан-доски не помогают
Когда говорят о проектах внедрения или разработки с нуля какой-то программы считается, что Канбан-доска решает все проблемы.
Недостатки
- Объектами проекта являются несколько основных элементов. Процедуры-функции-инструкции-фт-Объекты метаданных. Все они разные, имеют различающиеся характеристики. Если все эти объекты превратить в "задачи", то в общей сложности по математике, представленной выше, средний проект внедрения ERP систем будет иметь около 2000 таких элементов. Все их поставить в плоскую таблицу нельзя. На экранах популярных канбан-досок помещается до 10 элементов. Что будет, если разместить 2000 элементов на доску канбан?
- Отдельные элементы проекта, такие как Процедуры, функции-ФТ имеют различные статусы. Для Процедур и функций это "подготавливаются", "обучение", "передача в эксплуатацию". ФТ в свою очередь "на согласовании заказчиком", "на согласовании РП", "на разработке ТЗ" и так далее. Чтобы расположить их на нужных колонках, придется постараться. Поэтому колонки канбана максимально упрощены. Например, " в работе" для ФТ может означать - и на разработке ТЗ аналитиком и на программировании и проверке. Выход - множество канбан досок. Канбан доска действительно нужна только программисту, который решает конкретно полученные ТЗ и поставил их в очередь. Начать-Тестировать-завершить и так сотни раз. Для РП и аналитиков Канбан-доска слишком низкоинформативна и не учитывает специфики "задачи" - процедура эта или функция. В начале проекта у аналитика с точки зрения канбан-задач действительно несколько сотен задач, которые вообще нет смысла наносить на доску.
- Для проекта важны не оставшиеся задачи, а выполненные. Именно группировка и анализ выполненного и позволяет судить о готовности проекта.
