Автоматизируя хаос, получим автоматизированный хаос. А если конкретно, то прежде чем приступать к доработке программного продукта, необходимо проанализировать все процессы, протекающие в компании, иначе процесс доработки может превратиться в бесконечную доработку доработанного.
Подписывайтесь на наш Телеgram!
Новости, анонсы, мастер классы и др. полезный контент для тех, кому важно быть впереди и в курсе темы
Этап предназначен для сбора и анализа подробной информации о предприятии Заказчика с целью проектирования системы. В рамках данного этапа:
Может проводиться как одним этапом, так и отдельными блоками, т.е. сначала описываем процессы логистики, потом продаж, потом производства.
Для формализации бизнес-процессов наши специалисты используют методику, базирующуюся на BPMN.
Данный этап работ позволяет найти узкие места в управлении бизнес-процессами компании, описать документооборот компании и изучить регламенты работы сотрудников. Данный этап полностью подготовит структурированную информацию для выполнения этапа консалтинга в компании.
Работы предназначены для описания ваших бизнес-процессов, разработки Функциональных требований, Технического задания и Контрольных примеров.
Вам нужно автоматизировать бизнес. С чего начать? Как это сделать правильно, чтобы ничего не упустить и по результату получить полноценный ИТ-инструмент для развития бизнеса? Ведь времени, денег и других ресурсов в автоматизацию придется вложить немало.
В видео мы обсуждаем ключевые вопросы подготовки к внедрению, потому что именно от этапа подготовки и моделирования зависит непосредственно весь последующий процесс разработки и внедрения.
Внедрением систем мы занимаемся уже 15 лет, и за это время провели немало разнообразных проектов.
Используя разные методологии, подбирая нужные инструменты, на сегодня мы сформировали свой практический подход. Именно так мы делаем у себя в компании и работаем с нашими заказчиками. Это наиболее рациональный подход с наибольшей точностью и эффективностью.
В корпоративных проектах фаза моделирования у нас делится на три этапа:
Часто компании пренебрегают экспресс-обследованием, считая, что для проведения тендера достаточно самостоятельно сформировать некий список требований к системе. Это приводит к тому, что предложения на тендере очень сильно удивляют заказчика, и выбрать подрядчика становится очень трудно.
Мы обосновываем клиенту необходимость экспресс-обследования и еще до начала проекта его проводим.
Все про экспресс-обследование подробно описано здесь >>>
Из 9 разделов рассмотрим здесь те, что подготавливают информацию для описания бизнес-процессов:
Мы формализуем требования верхнего уровня, фиксируем список бизнес-процессов компании, которые нуждаются в автоматизации. Описываем их укрупненно, не расшифровывая до операций.
На основании списка бизнес-процессов проводим подбор одной или нескольких базовых систем.
Далее моделируем для выбранных систем - это дешевле, чем моделировать для нескольких вариантов, а уже потом делать выбор.
И дальше мы можем составить экспертную оценку, потому что именно это интересует заказчика - цена проекта и сроки выполнения.
Как проводить оценку - об этом можно посмотреть видео на нашем канале.
PERT: Project Evaluation and Review Technique — техника оценки и анализа
По методологии оценка выставляется на основании 3-х позиций:
И для того, чтобы получить единую, наиболее взвешенную цену, которая и интересует заказчика, есть методика ее расчета.
Подробно в статье и видео: Трехточечная оценка >>>
Оценка даст предварительное, максимально приближенное значение бюджета, детализированное настолько, насколько глубоко мы расписали задачи.
Но каким бы научным и проверенным ни был метод трехточечной оценки, на практике мы столкнулись с тем, что ее недостаточно на очень ранних стадиях проекта. Поэтому мы используем еще 2 методологии, мы ввели их в этом году.
Зафиксированные требования, которые нужно автоматизировать в системе, нужно посчитать по функциональным точкам и разделить их соответственно на разные классы: простые, средние и сложные.
Для каждой функциональной точки определяется ряд итераций, которые нужно пройти, для того чтобы процесс заработал - это, например:
Кроме оценки каждой точки в часах, выставляется еще одна оценка - грейды, потому что работы делают специалисты разного уровня квалификации.
Тарифы оплаты труда соответствующих специалистов отличаются, поэтому такая оценка значительно уточняет бюджет. Этого нельзя сделать в трехточечной оценке.
Как дополнительную методологию мы используем экспертизу. Она очень простая с точки зрения количества действий, но требует наличия высококвалифицированного специалиста.
У людей, которые поработали в какой-то отрасли довольно большое количество лет, есть predict-видение того, сколько займет та или иная работа. Этим занимаются PM.
Опытный специалист, прочитывая все требования, понимает, какая команда и на какой срок нужна для выполнения проекта. Это закладывается в оценку.
На сегодняшний день, когда мы выполняем экспресс-обследование, мы выполняем все три оценки, по трем вышеперечисленным методологиям.
И, естественно, все оценки дают разные цифры. Далее для этих оценок мы строим сетку, на оси Х и Y откладываем время и стоимость. Чем ближе разные оценки, тем они более вероятны.
На практике разлет по деньгам или срокам бывает очень большим. И самый простой метод получить усредненную оценку - найти пересечение биссектрис.
По результатам оценок мы обязательно проводим внутреннее совещание. Его нельзя назвать простым. Вся команда защищает свои оценки. Мы выясняем, почему тот или иной человек выставил именно такую оценку. Так мы убеждаемся, что никто ничего не пропустил.
По всем уточнениям рассчитываем усредненную оценку. Она и берется за основу предоставляемого клиенту расчета бюджета.
Так много внимания нужно уделить оценке! А ведь это всего лишь предварительно, и даже еще не принято окончательное решение о том, состоится ли вообще проект. И клиенты часто считают, что не так все это важно для выбора подрядчика.
И вот пример из практики: что бывает, когда экспресс-оценки нет. Это реальный недавний тендер, буквально нескольких недель давности, который проводила одна из компаний. Он открыт и есть на ProZorro, и мы в нем участвовали.
Участвовало много компаний, все они получили один и тот же список требований.
Разлет оценок по сформулированным заказчиком требованиям составил шестьдесят пять раз!
Человека, который оперирует финансами, эти цифры должны вводить в ступор и непонимание: что-то здесь не так. Исходя из здравого понимания, не может один подрядчик сделать это за 15К, а другой за это же запрашивать 1 миллион.
Получив разнообразные оценки тендера, чтобы как-то системно подойти к выбору, заказчик тоже применяет методологию отбора подрядчиков, нанося на сетку координат бюджеты и отсекая по краям: отсекаются самые дорогие и самые дешевые, и к рассмотрению принимается основная группа наиболее плотно расположенных оценок.
Для объемных и сложных проектов - например, внедрения BAS ERP - выбирать подрядчика по предварительной цене без обследования на сегодняшний день ошибочно и рискованно. Потому что средняя цена, которая обозначается на графике, может быть взята подрядчиками из опыта ведения проектов с другими системами, но похожими масштабами предприятия. И это вообще не про BAS ERP.
Потому что экспертизы на сегодняшний день есть всего у 5 компаний на рынке, у кого 3 и больше проектов по этой системе, и они уже знают, как это происходит, и могут оценивать.
Возможно, одна точка с высокой ценой для проекта по BAS ERP более правильная.
Когда мы делаем экспресс-обследование, мы предупреждаем заказчика, что наша оценка может выходить за рамки среднего бюджета, который предложат на тендере. Но по результатам обследования клиент получает документ с исчерпывающей информацией для выхода на открытый тендер.
То есть этот документ дает более полное представление о том, какая сложность и структура проекта, и повышает достоверность оценки всеми участниками тендера.
На следующих этапах мы формализуем все имеющиеся требования к системе.
Очень часто заказчик пытается пропустить описание текущего состояния процессов as-is и поскорее приступить к описанию желаемой картины to-be. Но это ошибка.
Когда мы описываем to-be (как будет), нужно понимать, что оптимизировать и изменять, и это можно сделать, когда мы разобрали и расписали процессы (как работает сейчас as-is). Тогда можно определить, какую часть процесса изменять. Кроме того, в новой системе могут быть свои правила ведения процессов. То есть to-be всегда будет отличаться от as-is.
И тут очень важный момент: нужны обе схемы - as-is и to-be - для того, чтобы построить стратегию, и организационную матрицу перехода, и техническую.
Какая это матрица может быть? Самая простая - когда у нас есть два описания: как есть и как будет, и составляется перечень всех отличий. Это описание будет слабо структурированным, но очень простым, и часто этого достаточно.
Более сложная матрица перехода составляется как таблица и содержит описание процессов как есть и как будет, а далее выделяются объекты, которые в будущей модели будут отличаться от текущей. Дополняется таблица процессами, которые можно создавать, применять к объектам или трансформировать.
На следующем шаге в такую таблицу добавляются роли, и это позволяет сопоставить определенные роли с процессами, проанализировать их и составить план дальнейших действий по проекту.
В некоторых случаях нам нужно не просто новую систему поставить, нужно поменять компанию организационно: появятся новые роли, новые задачи и должностные инструкции, многие меняются и дополняются. И только при этих условиях внедрение системы даст улучшения.
По такой же схеме (было-будет) анализируется и документооборот, например, “был такой процесс в 4 документа, а стал вот такой процесс и он будет в новой системе отображаться так…”.
Более сложный анализ выйдет, если соединить изменение документооборота с изменением процессов. Для этого составляется таблица, где поблочно расписывается, какие нужны трансформации, чтобы as-is преобразовать в to-be. По итогу составляется план действий - это и есть матрица перехода, которая описывает, что нужно делать организационно для того, чтобы этот процесс заработал, как задумано. Новой системы для этого недостаточно, еще есть организационные преобразования.
Основной целью документа Функциональные требования является получение Гэпов (Gap - зазор - определяется как незаполненное пространство или интервал). Мы должны промоделировать на системе, что у нас покрывается типовым функционалом, а что не покрыто и требует доработки. Именно этот список Гэпов является основой для написания технического задания.
Здесь уже большое разнообразие элементов, среди них есть очень болючие. И от проекта к проекту они разные: для кого-то очень болезненный вопрос НСИ и переноса этих данных, для кого-то совсем другое.
Очень часто именно интеграции - это большая “головная боль” любого проекта, потому что на сегодняшний день очень много у компаний ИТ-инфраструктуры, она представляет собой широкий спектр всевозможных систем: учетная система, бухгалтерская система, сайты, какие-то порталы клиентов, CRM-системы, платежные системы, мессенджеры. Все разнесено по разным системам, и, приступая к новому внедрению, один кусок процессов нужно заменить на другой, который отличается, и это влечет изменения в структуре самих интеграций. И нужно предварительно к этому моменту построить схему изменений, построить шины данных. Возможно, нужно использовать старые системы в части передачи данных. Но однозначно необходима стратегия, как мы будем оперировать теми данными, которые у нас были, в новой системе. Можно ли использовать куб данных, шину данных, старую систему или доступ к части функций?
У каждого проекта план интеграций будет осуществляться по-разному.
Для построения стратегии нужна еще техническая матрица перехода, и ее построение тоже непростой вопрос.
В технической матрице перехода мы оперируем логическими понятиями: где какая система находится, и какую функцию на каком уровне она выполняет, то есть на уровне какого сервера какая система стоит, с чем он взаимодействует и т.д. И эту структуру в рамках проекта нужно будет изменять, потому что, если в процессе проекта у вас меняется бизнес-логика и нужны изменения доступа к данным, перейти от одной технической инфраструктуры к другой иногда бывает очень непросто.
Особенно очевидно это для высоконагруженных систем. Для них, кроме прочих, еще есть требования высокой скорости обработки данных.
Такие решения не всегда строятся на платформе BAF или какой-либо другой платформе.
Иногда базовая конфигурация ПО вообще не используется, и система разрабатывается с нуля. Иногда это делается на чистых языках, иногда для этого вообще используются какие-то внешние сервисы.
Вариантов решений много, и подбираются они индивидуально непосредственно под требования бизнеса.
Когда уже есть техническое задание, очень хорошо работает трехточечная оценка. Когда мы с верхнего уровня, от очень высокоабстрактной задачи, опустились до уровня задач по типу “надо реализовать справочник Х, документ Y, печатную форму Z”, тогда оценка трудоемкости и расчет стоимости становятся понятными. Поэтому для оценки по техническому заданию мы уже не пользуемся другими инструментами, и используем только трехточечную оценку.
Какие рекомендации можем дать для старта проекта по внедрению системы BAS ERP? Их мы сформировали после более десятка различных проектов.
Вначале, когда продукт был новый, еще отсутствовали обучающие курсы, и у заказчика не было возможности ознакомиться с архитектурой и логикой работы нового программного комплекса. Это значительно затягивает процесс принятия решений, потому что команду заказчика необходимо сначала учить.
Мы рекомендуем до начала проекта вашу рабочую группу отправить на обучение.
Мы проводим очень много различных тренингов, как по общей концепции системы, так и по определенным подсистемам, если, например, вы хотите запускать определенную подсистему. Есть отдельные программы обучения по BAS ERP, и по BAS УХ, и перед стартом внедрения их нужно прослушать. Такое обучение помогает общаться на одном языке с аналитиками, которые будут описывать процессы. Станет намного понятнее подготавливаемая документация и решения, исходящие из архитектуры самого продукта. И это значительно экономит время, и, соответственно, окупается, и, конечно, улучшает качество принимаемых решений по проекту, поскольку основано на знании.
Для того, чтобы аналитик мог полноценно пройти предпроектный этап, ему, кроме знакомства с системой, понадобятся еще знания: каким образом описывать процессы, как моделировать, как в техническом задании описывать, что должно быть доработано, как интегрировано и много еще.
Мы проводим отдельный тренинг по обследованию и моделированию в корпоративных проектах, он идет один день.
На странице тренинга есть подробное описание, будет объявлены место и дата следующего тренинга >>>
Прохождение такого тренинга, если у вас уже запущен проект, позволит проще разбирать документы, которые вам предоставляются. А в целом тренинг мы построили так, чтобы после его прохождения ваша внутренняя команда могла сделать это самостоятельно - пройти все три стадии, от экспресс-обследования до написания функциональных требований и моделирования.
На тренинге мы рассказываем о нотации BPMN. Нотаций есть еще несколько, и возможно использование других. Процессы as-is могут быть описаны в вашей нотации.
Мы выбираем BPMN, потому что она легко читается и является самой простой для понимания системой нотации.
На основании полученных знаний уже можно составлять техническое задание - и это уже документ для более точной оценки проекта.
Это краткий обзор курса.
Вопрос: “Реально ли за один день всему научиться?”
На самом деле в реальности тренинг рассчитан дать базис, основной скелет практических знаний, для того чтобы вы знали, куда дальше копать. Понятно, что сам BPMN можно учить три месяца. И глубина вашего освоения знаний зависит уже от количества потраченного вами времени, усилий и поставленных целей. Но понимание, каким образом это делать, у вас появится.
Естественно, потом нужно будет приобрести еще четыре книги и разбираться с каждым вопросом внутри отдельно, и прорабатывать каждый из них на практике уже непосредственно в вашем проекте.
Видео о ключевых моментах внедрения систем автоматизации на канале TQM systems: кейсы, примеры внедрений, методики работы, параметры выбора, новые разработки и возможности.
SaaS сервисы
Программы 1С:Підприємство
CRM
ERP
Node.JS, .NET
1С:Підприємство
API, IPasS
Разработка Web Apps
1С:Підприємство Автоматизация
Аудит IT проектов
Интеграция 1С:Підприємство
Получайте наши информационные материалы:
Работаем на IT-рынке с 2008 года.
Наша миссия - упростить управление данными.
Copyright © 2008-2024 TQMsystems. Все права защищены. Privacy Policy | Terms of Service