Процессная модель внедрения. НЕ КАНБАН и AGILE

05.07.23

Функциональные - Управление проектом (PMO, EPM)

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

Начать придется с эпического фЭйла, когда пришел функциональным архитектором в крупную металлургическую компанию на проект внедрения ERP и получил в качестве системы управления проектом файл MS Project c датой начала проекта и датой внедрения. При запрещенных каких-ли облачных сервисах (безопасность) пришлось вертеться. Уже много позже "карманная" конфигурация 1С, в которой создавал отдельные списки объектов, превратилась в довольно логичную и простую "коробочную" конфигурацию, в которой работает моя проектная команда с несколькими проектами одновременно. 

 

Что такое ERP-Tools

Чтобы построить высокое здание, требуется сначала поставить башенный кран и получить проект дома. ERT-Tools это кран и проект строительства одновременно. Как это работает:
 

  1. Приобретаете конфигурацию и устанавливаете на внутреннем сервере.
  2. Программа содержит 2 взаимосвязанных раздела "Функциональное моделирование" и "Сервис-деск". Эти инструменты на 95% обеспечивают накопление информации и обмен внутри проектной команды.
  3. Получаете работоспособную технологию выполнения проекта, следуя которой, вы четко идете к передаче проекта в эксплуатацию.
  4. Не нравится команда, РП или архитектор - поменяйте без рисков для проекта в целом. При соблюдении проектной технологии риски потерь ключевого сотрудника "который все знает" крайне низкий.
  5. Тестируете итоговую функциональность и запускаете в эксплуатацию.
  6. После начала эксплуатации продолжаете развивать учетную систему с помощью ERP-Tools

 

Опишу традиционный кейс внедрения ERP, которым и сам пользовался, пока не понял, что база данных сильно лучше файлов.

 

Традиционная технология и инструменты

  1. Найти на рынке Руководителя проектов, который почему-то свободен. Услышать от него, как он где-то что-то внедрял, не всегда удачно, так как кругом были враги.
  2. Найти аналитиков, которые почему-то свободны. Поверить, что все они знают, что делать.
  3. Собрать функциональные требования на интервью - MS Excel с перечнем ФТ.
  4. Понять, что совместно работать с единым файлом невозможно - перенести файл на Google tab.
  5. Попробовать реализовать ФТ штатными средствами, а в случае неудачи - зарегистрировать функциональный разрыв.
  6. Понять, что Google tab не удобен для работы даже 2 человек. Найти канбан-доску на облачных сайтах. Помещать туда только ФТ с признаком Разрыв.
  7. Создать Техническое задание - MS WORD. На всякий случай аналитик запустит его через почту в адрес всей команды. Кто-то подправит ТЗ и также его запустит в почту. Теперь крайняя версия ТЗ существует исключительно в почте. Ежедневно все члены проектной команды получают десятки писем, не совсем понятных, для кого они предназначены в первую очередь.
  8. Согласовать ТЗ - Почта, чаты.
  9. Выполнить разработку по ТЗ.
  10. Установить статус "Выполнено" у функционального требования в Google tab.
  11. На вопрос о степень готовности проекта - показать таблицу с перечнем реализованных ФТ и резюмировать: "Почти готово. Но кое-что еще нужно править".

В результате, как правило, получается "файлопомойка" с единственным актуальным файлом с перечнем ФТ и набором файлов разной степени актуальности.


Преимущества:

  • Любой человек может стать руководителем проекта, главное - быть администратором файла с ФТ, участвовать в 100% обсуждений, замыкать все на себя.
  • Аналитик любого уровня компетенции может делать проект в том стиле, котором хочет - главное, чтобы заносил в файл с ФТ ее текущий статус.
  • Любой провал можно объяснить общим бардаком в компании.

Недостатки

  • Надо договориться о совместном использовании файлов, чтобы 2 аналитика одновременно не входили в файл Excel или не ставили фильтры в Google таблицах.
  • Как именно работает система - не совсем понятно. Функциональное требование само по себе не говорит о том, в каком процессе оно участвует. Это вырванное из контекста (бизнес-процесса) поведение системы.
  • Критически важно удерживать членов команды, чтобы не потерять контекст. Уйдет РП - проект можно закрывать.
  • Команда может работать с файлами разных версий, выполнять задачи, которые никому не нужны. Часто фиксируются только ФТ с признаком разрыва и по факту весь проект это "перечень нештатных доработок" без какого-либо взгляда "сверху".
  • Архитектор должен быть в контексте всех задач всех аналитиков, так как это единственное связывающее звено. Архитектор должен делать вид, что все помнит и знает. Уходить в отпуск архитектору нельзя.
  • Нормальный пакет инструкций по ERP-проекту может достигать 1000 страниц. Найти нужную в сотнях файлов практически невозможно. Поэтому большинство инструкций делается "для галочки", так как ее все равно никто не прочитает. Пользователь запросил инструкции по какому-то действию? Пусть получит ее в виде скрина прямо в письме.
  • "Процессная" методика внедрения с использованием MS Office или облачных "канбан" систем нереализуема на практике

 

А теперь то, что работает на практике на сложных проектах с сотней рабочих мест с рабочими группами от 10 человек.

ERP-tools технология


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

Основным объектами внимания являются:

Процедуры - функции - инструкции - функциональные требования - объекты метаданных. 

Тут я в явном виде перечисляю, а не скрываю общие термином "отдельные моменты проекты". Вот эти 5 объектов являются центровыми, вокруг которых и строится технология.
 

  1. Выявить Процедуры - существующие бизнес-процессы заказчика (Например, "Продажа клиенту")
  2. Определить шаги выполнения процедур - Функции (создать заказ, выставить счет, получить оплату, Отгрузить товар). Отдельная функция - это единичное действие с объектом метаданных системы - справочниками и документам.
  3. Начать моделирование системы, создавая Инструкции по каждой функции, получая инструкцию по Процедуре в целом.
  4. В ходе написания инструкции задавать вопрос - является ли текущее действие "функциональным требованием". Если да, то регистрировать Функциональное требование ("Отгружать только по предоплате","отгружать одним документом с 2 складов"). ФТ это не функция - это особенность выполнения отдельного шага функции, о котором в явном виде нужно спросить у бизнес-пользователя.
  5. Показать инструкции заказчику, согласовать все выявленные ФТ, получить дополнительные требования. Часто это ФТ с признаком Разрыв ("Хочу такое же, но с перламутровыми пуговицами")
  6. Подготовить "дизайн" преодоления разрыва (пользовательская история), согласовать с заказчиком, писать подробное ТЗ.
  7. Передать ТЗ на оценку архитектору, потом на реализацию программисту. По итогам проверки - создать Протокол доработки. На этом этапе в ERP-Tools используются Заявки и канбан-доски с типом "поручение".
  8. Контролировать выполнение текущих поручения от коллег/коллегами с помощью Канбан досок. Комментировать выполнение задач.
  9. Внести изменение в действующую инструкцию, показать обновленную инструкцию заказчику.
  10. Если заказчик удовлетворен выполнением функции - установить у нее соответствующий статус
  11. Если у процедуры все функции достигли высшего статуса ("заказчик удовлетворен"), значит вся процедура полностью удовлетворяет заказчика.
  12. Готовность проекта к эксплуатации достигается при 100% готовности всех Процедур.

Все эти действия происходят внутри ERP-Tools без использования MS Office, обеспечивая скорость выполнения проекта и его качество.

Результатом является четкий бизнес-процесс, по которому должны пройти 1 тысяча функциональных требований, 10% из которых в среднем является функциональным разрывом. Количество описанных "бизнес-процессов" достигает 100 и более, описываются порядка 500 функций по учету действий над более 100 объектов системы - отдельных справочников и документов.

Заказчик получается полностью документированную базу данных обо всех измененных Объектах Метаданных, с актуальными ТЗ, протоколами, и исчерпывающими инструкциями, подтверждающими, что команда действительно выполняет проект.

Преимущества:

  • Четкий бизнес-процесс для аналитиков
  • Возможность работы действительно большой команды - десятки аналитиков имеют 100% доступ к нужной информации, визуализируют ее так, как им нужно в этот момент, не мешают друг-другу, используют инструкции коллег.
  • Функциональный архитектор не должен быть погружен в сотни разработок, делегируя функции контроля базе данных.
  • Аналитик отвечает за блок, а архитектор отвечает за аналитика и его качество работы.
  • Заказчик четко видит результат - от первичного ТЗ до инструкции. Становится понятен процент реализованных ФТ, процедур.
  • База данных хранит все вмешательства в конфигурацию с указанием скорректированных объектов, причин, инициаторов, нового поведения системы (протоколы испытаний).
  • Полная и всегда актуальная wiki для будущих пользователей системы, где они могут посмотреть - как должна выполняться отдельная операция. Нет нужной операции - Аналитик должен зарегистрировать Процедуру, определить шаги-функции, написать инструкции.
  • Выполнив 100% ФТ, произведя обучение по 100% процедур скорее всего достигается целевая архитектура.
  • Статус готовности проекта всегда виден - смотрите готовность Процедур.

Недостатки

  • Нужно выполнять четкий процесс, а часто этого не хочется делать, например, поставив ТЗ в чате программисту или даже позвонив по телефону.
  • Аналитик, архитектор и даже РП перестает быть критически значимым сотрудником.

 

Почему Канбан-доски не помогают


Когда говорят о проектах внедрения или разработки с нуля какой-то программы считается, что Канбан-доска решает все проблемы.
 

Недостатки

  1. Объектами проекта являются несколько основных элементов. Процедуры-функции-инструкции-фт-Объекты метаданных. Все они разные, имеют различающиеся характеристики. Если все эти объекты превратить в "задачи", то в общей сложности по математике, представленной выше, средний проект внедрения ERP систем будет иметь около 2000 таких элементов. Все их поставить в плоскую таблицу нельзя. На экранах популярных канбан-досок помещается до 10 элементов. Что будет, если разместить 2000 элементов на доску канбан?
  2. Отдельные элементы проекта, такие как Процедуры, функции-ФТ имеют различные статусы. Для Процедур и функций это "подготавливаются", "обучение", "передача в эксплуатацию". ФТ в свою очередь "на согласовании заказчиком", "на согласовании РП", "на разработке ТЗ" и так далее. Чтобы расположить их на нужных колонках, придется постараться. Поэтому колонки канбана максимально упрощены. Например, " в работе" для ФТ может означать - и на разработке ТЗ аналитиком и на программировании и проверке. Выход - множество канбан досок. Канбан доска действительно нужна только программисту, который решает конкретно полученные ТЗ и поставил их в очередь. Начать-Тестировать-завершить  и так сотни раз. Для РП и аналитиков Канбан-доска слишком низкоинформативна и не учитывает специфики "задачи" - процедура эта или функция. В начале проекта у аналитика с точки зрения канбан-задач действительно несколько сотен задач, которые вообще нет смысла наносить на доску.
  3. Для проекта важны не оставшиеся задачи, а выполненные. Именно группировка и анализ выполненного и позволяет судить о готовности проекта.

ERT-Tools Внедрение сложных систем ERP-класса переход с SAP на 1С и обратно.

См. также

Бухгалтер vs ERP

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Большинство бухгалтеров привыкли вести учет в конфигурации 1С:Бухгалтерия. Но что бывает, если такого бухгалтера перевести с 1С:Бухгалтерии на ERP? Об основных ошибках бухгалтера после перехода и роли аналитика в том, чтобы помочь бухгалтеру преодолеть трудности и изменить привычные паттерны, пойдет речь в статье.

15.05.2024    3570    0    TanyaRi    66    

25

Как мы оптимизировали процессы внедрения 1С: проектная методология КРОК

Внедрение изменений Бесплатно (free)

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

15.05.2024    4891    0    cesar    15    

47

Переход на современные ERP-решения «1С» – дорожная карта, кейсы, рекомендации

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Статья об основных зонах внимания и часто допускаемых ошибках при внедрении современных ERP-систем – «1С:ERP Управление предприятием» и «1С:ERP.Управление холдингом».

27.04.2024    1825    0    user893825    0    

17

Как внедрить 1С:ERP за 2 года и не сойти с ума

Анализ предметной области Анализ потребностей и поиск решений Внедрение изменений Бесплатно (free)

Для руководителей подразделений новые проекты вызывают желание получить максимальный эффект от реализации идей, а также опасения, верно ли выбран ориентир нововведений. О том, как справиться с трудностями, дойти до цели и внедрить 1С:ERP на производственном предприятии, ежедневно выпускающем десятки тысяч единиц готовой продукции, расскажем в статье.

30.01.2024    7816    0    user1578851    16    

22

Я - ЗУПер! Часть 4. Проблемы, возникающие при заключении договоров

Бизнес-анализ Платформа 1С v8.3 Сложные периодические расчеты 1С:Зарплата и Управление Персоналом 3.x Бесплатно (free)

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

07.08.2023    5314    0    biimmap    43    

57

Внедрение системы технологического контроля (практический кейс)

Кейсы автоматизации Внедрение изменений Пользователь Платформа 1С v8.3 1С:Управление нашей фирмой 3.0 Управленческий учет Бесплатно (free)

Стабильное качество выпускаемой продукции и ее соответствие нормативным документам (ТУ, ГОСТам, СМК) для активного предприятия является конкурентным преимуществом, так как оно подчеркивает, что на предприятии отлажены контрольные процедуры на входящее сырье, производство полупродуктов и готовой продукции, доставки. В своей практике я принимал участие во внедрении цифровых инструментов в сельском хозяйстве, где показателями зерна служат влажность, засоренность, крупность и т.д.; в металлургии — перед литьем в формы надо проверить сплав на содержания железа, алюминия, магния и т.д.; в кабельной промышленности в дополнение к физическим свойствам типа геометрии, длины, шероховатости, надо выдерживать и электротехнические показатели. 

22.05.2023    1597    0    Ingraf    0    

16

Трекер задач

Управление проектом (PMO, EPM) Пользователь Руководитель проекта Платформа 1С v8.3 Россия Управленческий учет Абонемент ($m)

Еще один трекер задач для 1С, но реализован на html + css + js. Успешно используется в собственной срм в повседневной работе. Конфигурация написана на базе БСП 3.1.5.306.

2 стартмани

24.04.2023    8658    83    andrybar    16    

69
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. sapervodichka 6839 05.07.23 22:13 Сейчас в теме
Мы с коллективом наоборот отходим от ERP-tools технологии в работу с Канбан.
Я примерно в 30 проектах внедрения УПП, ЕРП и УХ полного цикла участвовал и знаете с Канбаном гораздо лучше едет.
rpgshnik; +1 Ответить
3. DenisErmolaev 15 06.07.23 08:56 Сейчас в теме
(1) А что является объектом канбана? Можете пояснить. Задача? Доработка? Как считаете степень готовности проекта к запуску? В каком виде хранятся и обновляются инструкции?
5. sapervodichka 6839 06.07.23 09:55 Сейчас в теме
(3) канбан кончено я имею ввиду, не только саму доску, но и выпуски релизов, задачи, чек листы, файлы, версии, учет затрат, интеграции с хранилищем и мессенджерами и т.д. https://infostart.ru/1c/tools/552480/ вот тут можно посмотреть исходники (у меня в ходе практики допилена поудобнее)

Объектом является задача, подзадача, подзадача и т.д.. делятся как на консультантов так и на разработчиков
Инструкции к задачам верхнего уровня обычно, тех задания к подзадачам.
Вообщем очень гибко и по разному можно организовывать в зависимости от проекта.
7. DenisErmolaev 15 06.07.23 12:33 Сейчас в теме
(5)
верхнего уровня обычно, тех задания к подзадачам.
Вообщем очень гибко и по разному можно организовывать

Вообщем очень гибко и по разному можно организовывать в зависимости от проекта.

У меня к сожалению не гибко. любые ЕРП-проекты идут по единому сценарию:( Копи-пастишь процедуры из похожих проектов, копи-пастишь ФТ, которые надо согласовать. Никакой гибкости. Все просто и единообразно:( Никаких подзадач. Предсказуемо. Рутинно.

Если гибкость - то значит все зависит от владельца продукта/РП/Архитектора. Гибкость - это преимущество Excel. Гибкость - это фристайл. Как вам -"прораб был гибок". Привык РП к гибкости - если для заказчика экспромт допустим, ну ОК. Я как раз от гибкости и ухожу в стандартизацию. И то, что вы показали - это инструмент разработки. В ERP-Tools его (почти) нет. Для меня важно визуализировать и описать действующую/целевую функциональность. В моей технологии Процедура - это "задача", которая никогда не завершится. У нее меняется статус - от "неописанной" к "описанной". Если процедура ушла на ремонт/доработку - значит нужно не забыть ее понизить, доработать, а потом изменить инструкции и вернуть ее в бой. Это довольно многозадачная история. И вы не ответили на вопрос - как будет выглядеть доска, куда хотя бы попытаться записать 100 функциональных разрывов. Примеры досок с 5 задачами впечатляют, но таких досок нет в проектах внедрения. Точнее это доски программистов, которые выполняют разработку в порядке четкой очереди. Аналитикам приходится применять гибкость в Excel.
8. sapervodichka 6839 06.07.23 15:52 Сейчас в теме
(7) у нас рыба базы внедрения ЕРП копируется из проекта в проект со всей документацией и примерно одинаковым планом работ (просто копированием базы)
100 и более функиональных разрывов красиво размещаются на доске, т.к. у нее есть отборы по ответсвенным, задачам, периодам и т.п. все одномоментно на доске не нужны на мой взгляд
6. пользователь 06.07.23 10:00
Сообщение было скрыто модератором.
...
2. siamagic 06.07.23 07:36 Сейчас в теме
Преимущества:

Любой человек может стать руководителем проекта, главное - быть администратором файла с ФТ, участвовать в 100% обсуждений, замыкать все на себя.
Аналитик любого уровня компетенции может делать проект в том стиле, котором хочет - главное, чтобы заносил в файл с ФТ ее текущий статус.
Любой провал можно объяснить общим бардаком в компании.


Это пять!

(1) Канбан для дураков, так что среди них оно конечно лучше едет.
4. DenisErmolaev 15 06.07.23 09:05 Сейчас в теме
(2) Зачем так. Канбан для поручений и однотипных задач. Для самоконтроля подходит. Но для работы 15 человек над одним проектом мне не удавалось реализовать. В моем подходе программисты и сидят на канбан доске. Им поступают структурированные задачи в виде тз. Их надо отщелкать. Аналитикам и архитектору Канбан не подходит, так как неинформативен. Мои коллеги основную документацию выкладывают на confluence в виде сайта. Если сравнивать что удобнее - условный плоский сайт/word или база данных, где все хранится на полочках и может отобразиться в любой комбинации, где можно любую бизнес-логику заложить. По мне так база данных надежнее и удобнее. С Сайтом одна беда - его должен строить один человек. Иначе он потеряет стройность. В базу данных можно заложить логику и правила. От них никуда не деться.
Оставьте свое сообщение