Фаза моделирования в ERP проектах

Фаза моделирования в ERP проектах. Выступление на ERP-форуме

С чего начинается проект для крупной компании? С поиска выгодного предложения? Выбора подрядчика? Изучения рынка? Составления требований? Уже теплее. Как, желая начать правильно и самостоятельно, не угодить в ловушку. Как не закапываясь в многочисленные детали на старте, подобрать правильные решения, минимизировать риски и адекватно все оценить: бюджеты, подрядчиков, свои силы.

Подписывайтесь на наш Телеgram!

Новости, анонсы, мастер классы и др. полезный контент для тех, кому важно быть впереди и в курсе темы

Выступление на ERP-форуме: 

• Методология, которую мы на практике используем в компании TQM systems - это результат 15-летнего опыта.
• Как выстраивается оценка.
• Как подготовится к тендеру, выбрать подрядчика, и почему отсечение самых дешевых и дорогих не работает для сложных проектов. 
• Переход к новой системе - как не зашить в нее старые проблемы. 
• Технические и организационные вопросы в нашем материале.

Видео о этапе моделирования в крупных корпоративных проектах смотрите на нашем Youtube-канале:

Содержание:

• Наша методология - это результат 15-летнего опыта внедрений.
• Этапы подготовки: экспресс-обследование, функциональные требования, техническое задание.
• Если не делать предпроектное обследование и со своими требованиями выйти на тендер, что будет.
• Что мы делаем на этапе экспресс-обследования и зачем.
• Трехточечная оценка - часть методологии PERT-анализа, как правильно посчитать стоимость проекта.
• На ранних стадиях проекта цену определить гораздо сложнее, поэтому применяем еще 2 методики.
• Метод функциональных точек для оценки задач по степени сложности.
• Когда нужно использовать грейды по уровню квалификации специалистов: Junior, middle или senior.
• Экспертиза от специалистов с опытом работы в аналогичных проектах: насколько это оправдывается.
• Если оценки по разным методологиям отличаются, а клиенту комфортно услышать одну цену.
• Зачем обсуждать каждый из вариантов оценки?
• Пример реального тендера на ProZorro, когда оценка выставлялась без предварительного обследования.
• Выбор подрядчика: почему отсечение дешевых и дорогих не работает для сложных проектов?
• Как правильно подготовиться к тендеру, и получить адекватные оценки от подрядчиков?
• Переход из “as-is” к новой системе “to-be”, не зашив в нее старые проблемы?
• Матрицы перехода: когда достаточно простой, а когда нужно усложнять?
• Пример, когда вместо замены системы, нужна реструктуризация и новая оргструктура.
• Основная цель документа Функциональные требования.
• Почему интеграция часто становится головной болью проекта?
• Техническая матрица перехода и ее сложности. Требования для высоконагруженных систем. Когда легче разработать с нуля без платформ?
• Момент, когда проект можно точно оценить.
• Квалификация проектной группы заказчика.
• Тренинг по обследованию и моделированию в корпоративных проектах: что будет.
• Что команда заказчика может делать самостоятельно? Практика применения нотации BPMN.
• Можно ли научиться обследовать и анализировать, моделировать и составлять ТЗ за один день?

00:04 Методология, которую мы на практике используем в компании TQM systems, - это результат 15-летнего опыта внедрений.

Всем добрый день, меня зовут Зосим Максим. Я руководитель и основатель компании TQM Systems, сейчас она вот появятся на слайдике. И сегодня мы начнём раздел, который касается фазы моделирования в корпоративных проектах. Я занимаюсь этим уже чуть более 15 лет, и поэтому кое-что в этом понимаю, и до сих пор этим занимаюсь. У нас это не поддержка какой-то методологии. Именно так, как мы делаем у себя в компании, и то, как мы работаем с нашими заказчиками – именно эту методологию я буду рассказывать.

00:38 Три этапа предпроектной работы: экспресс-обследование, функциональные требования, техническое задание.

В корпоративных фаза моделирования у нас делится на три этапа: 

• этап экспресс-обследования,
• функциональные требования,
• техническое задание.

00:46 Часто компании пренебрегают предпроектным обследованием. Каковы последствия.

Внутри каждого из этих этапов есть подразделы. Очень часто первое, и Владимир упоминал уже в своей презентации – не делать чего-то. Да, очень часто вот именно этим этапом пренебрегают компании, начиная корпоративный проект. Они зачастую внутри у себя сформулируют какие-то требования к системе, и именно с этими требованиями и выходят на тендер. Чем это заканчивается – мы чуть позже посмотрим.

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

01:20 Что мы делаем на этапе экспресс-обследования и зачем

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

02:08 Трехточечная оценка - это часть методологии PERT-анализа, как правильно посчитать стоимость проекта.

Самое классическое – где-то, по-моему, в начале лета мы выложили… Кто не подписан у нас на YouTube-канале – заходим и смотрим. Там детальное есть видео про трехточечную оценку. Это часть методологии PERT-анализа, который оперирует тремя сущностями. Он берет самую минимальную возможность выполнения того или иного процесса. Он берет среднюю – ту которую чувствует эксперт. И он берет максимальную. То есть у нас, по сути, есть 3 оценки. Не одна, а три. Очень часто с нас что спрашивают? «Дайте нам, собственно говоря, какое-то одно значение». Ничего лучше чем вот эта формула, собственно говоря, не придумано. Да, это мы берем минимальное плюс 4 средних, и плюс максимальное и делим на 6. И у нас получается какой-то бюджет нашего проекта – то, насколько мы смогли его детализировать вниз.

03:00 На практике на ранних стадиях проекта цену определить гораздо сложнее, поэтому применяем еще 2 методики.

Мы столкнулись с тем, что данной методологии недостаточно на очень ранних стадиях проекта. Поэтому мы используем еще 2 методологии, мы ввели их в этом году.

03:10 Метод функциональных точек: позволяет оценивать задачи в зависимости от степени сложности.

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

И для каждой этой функциональной точки мы должны пройти какой-то ряд итераций, который нужен для того, чтобы это заработало мы должны их :

• описать. То есть сделать для них ФТ и ТЗ. 
• разработать;
• протестировать;
• имплементировать внутрь, как в системы, или внутрь организации – то есть это инструкции, обучения, еще что-то;
• все это проадминистрировать.

03:48 Когда нужно использовать грейды по уровню квалификации специалистов.

Почему разделение? Да потому, что для первых тут еще перемножено не просто часы, а там еще и разные grade. Потому что зачастую A, B, C вот эти делают разные специалисты. Для уровня А достаточно там Junior, middle. Для уровня B – это только middle. Для уровня С - это только senior, и там middle переходящий в него. Поэтому и тарифы перемножающиеся вот здесь – они, собственно говоря, отличаются. То есть то, что нельзя в трехточечной сделать. Это вторая методология, которой мы пользуемся в нашей оценке. И есть третья методология, она очень простая.

04:23 Экспертиза от специалистов с опытом работы в аналогичных проектах: что они могут привнести и насколько это оправдывается.

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

04:52 Оценки проектов, полученные по разным методологиям, обычно отличаются, но клиенту комфортно услышать одну цену. Как определить наиболее вероятную оценку?

На сегодняшний день, когда мы выполняем экспресс-обследование, мы выполняем все три оценки, все три методологии используем. И понятно, что все эти три методологии дают абсолютно разные цифры, и мы получаем вот такую картинку на выходе. То есть мы берем все эти три методологии, и откладываем на оси Х и Y соответственно месяца и там деньги какие-то, и пытаемся…

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

05:38 Почему возникает разница в оценках, помимо усреднения? Зачем нужно обсуждать еще и каждый из вариантов?

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

05:58 Пример реального тендера на ProZorro, когда оценка выставлялась без предварительного обследования.

А вот проблематика, собственно говоря, когда у нас этой экспресс-оценки нет. Этот реальный тендер, буквально нескольких недель давности, который проводила одна из компаний, он открыт, и есть на Prozorro, в котором мы участвовали. Как вам разлет в 65 раз? Это вот сформулированные требования. Все компании, то есть их там еще, наверное, несколько – все компании получили одни и те же требования, один и тот же список. И вот мы получаем. И внимание вопрос, о котором тоже упоминал Владимир: «Мы вот это будем выбирать?» То есть понимаем, что что-то здесь не так. То есть эти цифры должны человека, который оперируют финансами вводить в какой-то штопор и непонимание. То есть что-то тут не так – не может вот здесь быть 15, а тут миллион.

06:45 Как выбрать подрядчика, и почему отсечение самых дешевых и дорогих не работает для сложных проектов, например, внедрения BAS ERP?

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

07:14 Как правильно подготовиться к тендеру, чтобы получить адекватные оценки проекта от различных подрядчиков-участников тендера?

Для BAS ERP вот эта вещь является на сегодня, по моему мнению, является на сегодняшний день ошибочной. Потому что не факт, что все, кто попали вот здесь, не ошиблись. Возможно одна точка, которая находится вот здесь, более правильная. Потому что экспертизы на сегодняшний день 3+ проекта есть всего у там 5 компаний на рынке, которые можно там reference исходить, как это происходит. Поэтому очень аккуратно с этими вещами на стороне. Если вы проводите такой тендер, и вы получили такие результаты – то квадрат может быть вот здесь, к примеру. То есть это вот то, что стоит сейчас помнить и знать.

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

У нас есть вот некоторые заказчики, которых я вижу и некоторые партнеры, которые, собственно говоря, оценивали.

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

Вышли на тендер, определились с подрядчиком, который вам интересен, начинаем его делать.

08:28 Как подготовиться и выстроить переход из “as-is” к новой системе “to-be”, не зашив в нее старые проблемы?

Что мы делаем на следующих этапах? Мы формализируем уже все требования к системе, которые у нас есть. Очень часто этап, который пропускается – это вот этот. То есть очень часто заказчик говорит: «А давайте мы не будем описывать процессы «as-is», давайте мы сразу будем писать «to-be». Вот очень часто, каждый второй заказчик хочет сразу написать «to-be». И в этом есть ошибка, потому что, если вы находитесь в каком-то состоянии, а когда мы пишем «to-be», мы хотим что-то еще оптимизировать. Зачастую мы понимаем, что что-то в наших процессах не так. А даже если понимаем, и процессы будут «to-be» практически такие же, то в новой системе они ведутся не так. То есть «to-be» будет всегда от «as-is» отличаться.

09:12 Матрицы перехода: простая - когда ее достаточно, а когда нужно усложнять?

И тут очень важный момент, что нам нужно – это вот эти обе схемы, для того чтобы построить стратегию и так называемую матрицу перехода. Эта матрица перехода организационная, потому что будет еще одна – будет техническая. Какая это матрица может быть? Самая простая – это у нас есть два описания: есть описание «Как есть», и «Как будет». И мы видим, что тут чуть меньше текста, а тут чуть больше. То есть что-то здесь будет отличаться. Не очень явно, не очень понятно, но очень просто. Очень часто этого достаточно. Матрица перехода, как таблица. Есть процессы «Как есть», есть процессы «Как будет». И мы видим, что в таблице уже чуть более понятно, потому что появились какие-то объекты, которые отличаются от существующих. Шагаем чуть дальше – есть там какие-то роли у нас. У нас есть таблицы, и мы понимаем, что к определенным ролям у нас добавятся определенные процессы. И это нам дает возможность, собственно говоря, проанализировать, что нам нужно сделать.

10:08 Пример, когда нужно не просто заменить систему, а выстроить новую организационную структуру, и реструктуризировать документооборот.

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

Для анализа документооборота можно использовать тоже вот такую простую схемку. То есть был вот такой процесс там в 4 документа, стал вот такой процесс, вот он будет новой системе отображаться так.

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

11:01 Основная цель документа Функциональные требования определить, что покрывается типовым функционалом, а что требует доработки.

Основной целью документа «Функциональные требования» является получение gap-ов так называемых. То есть мы должны промоделировать на системе, что у нас покрывается типовым функционалом, а что у нас не покрыто типовым функционалом и требует доработки. Именно этот список gap-ов у нас является основой для того, чтобы дальше делать техническое задание. Там тоже довольно много всевозможных элементов. Я остановлюсь на некоторых, которые самыми болючими на самом деле являются. Хотя от проекта к проекту это могут быть разные вещи: у кого-то очень болящая вещь - это там НСИ и перенос этих данных, у кого-то совсем другие.

11:39 Почему интеграция часто головная боль проекта? Как предусмотреть варианты для всех составляющих ИТ-инфраструктуры?

Но очень часто именно интеграции – это такая большая попа-боль любого проекта. Потому что на сегодняшний день очень много в компаниях IT-инфраструктура, она представляет собой очень расширенный такой спектр различных систем: сайты, учетная система, бухгалтерская система, какие-то порталы клиентов, CRM-системы. Это все может быть разнесено по разным системам. И когда вы пытаетесь, кусок вырвать и вставить на его место новый кусок, в котором отличается процесс, то это создает и отличие, в общем-то, в структуре самих интеграций.

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

12:39 Техническая матрица перехода. Требования для высоконагруженных систем. Когда проще разработать с нуля без использования платформ?

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

13:34 Момент, когда проект можно точно оценить: уровень конкретных задач.

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

14:11 Понимание заказчиком архитектуры и логики работы значительно ускоряет работу. Квалификация проектная группа заказчика.

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

Вот САБ проводит очень много различных тренингов, как по определенным подсистемам, если вы хотите запускать определенную подсистему, так и по общей концепции системы. Там есть отдельно по BAS ERP, отдельно по BAS УХ. Есть отдельные тренинги, которые нужно прослушать. То есть они помогут вам общаться с аналитиками, которые придут вам описывать процессы на одном языке. То есть вам будет проще, как минимум, понимать эту документацию, и сам продукт.

15:14 Тренинг по обследованию и моделированию в корпоративных проектах.

Во-вторых – это, собственно говоря все то, что я рассказывал, если вы заметили. То есть я рассказывал какие-то поверхностные некоторые вещи. На самом деле каждый из тех пунктов: каким образом описывать процессы, как моделировать, как в техническом задании описывать – то есть, что должно быть доработано, по интеграции и так далее. Есть отдельный тренинг по обследованию и моделированию в корпоративных проектах. Он идет один день, веду его я со своим коллегой. Мы один уже делали в октябре, и следующий должен быть, там, по-моему, поменялось – там не 3 марта, а 2 марта. Это вот буквально вчера изменилось. В общем, следите за новостями на сайте САБ – там будет объявлено место и дата, собственно говоря, следующего тренинга.

16:01 Что и при каких условиях внутренняя команда заказчика может делать самостоятельно? Практика применения нотации BPMN.

Это позволит вам, мало того что, если у вас уже запущен проект, и вам позволит проще читать эти документы, которые вам предоставляются, это позволит на выходе из вот этого тренинга, мы стремимся к тому, чтобы ваша внутренняя команда, она могла сделать это самостоятельно. То есть чтобы вы смогли пройти все три стадии, о которых я говорил. То есть от экспресс-обследования до написания функциональных требований и моделирования мы рассказываем нотацию BPMN в этом тренинге. Их есть еще несколько. Возможно у вас уже в других нотациях есть, существует. Поэтому там, на слайде, я указал, что процессы «as-is» – они могут быть описаны в вашей нотации. Потому что иногда мы сталкиваемся с тем, что у компании уже написаны процессы «to-be», и мы в основном рассказываем, что BPMN легко читается, поэтому самая простая для понимания в этом вопросе система. И на выходе вы, собственно говоря, можете выйти там с техническим заданием – это будет уже документ для более точной оценки.

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

17:19 Можно ли научиться обследовать и анализировать проекты, моделировать требования и составлять ТЗ за один день?

Реально ли за один день чему-нибудь научиться?

На самом деле тренинг на то и рассчитан, чтобы дать базис для того, чтобы вы знали куда дальше копать. Понятно, что сам BPMN можно учить на самом деле три месяца. То есть там смотря куда мы стремимся, с точки зрения: «Что на выходе?» Но понимание, каким образом это делать, у вас появится. То есть понятно, что вам потом надо будет садиться, покупать еще четыре книжки, и ковыряться внутри, и отдельно проводить эти вещи.

Смотреть видео на нашем канале >>>

Видео о ключевых моментах внедрения систем автоматизации на канале TQM systems: кейсы, методики работы, параметры выбора, новые разработки и возможности.

Наши контакты >>>

Копирование текста возможно только со ссылкой на источник и указанием автора материала. Благодарим за уважение прав интеллектуальной собственности.

Редактор: Наталья Раевская

• 
• CEO TQM Systems Максим Зосим
• 1/27/2022 10:20:44 PM
• articles, Внедрение ERP