Обследование бизнес процессов для автоматизации

Про спагетти, или как исследовать бизнес-процессы организации

Про спагетти, или как исследовать бизнес-процессы организации

Многие руководители предприятий не обладают полной картиной происходящего в собственных производственных подразделениях. Они знакомы с организационной структурой, направлениями деятельности, общими экономическими показателями. Если по результату получилась прибыль, то наступает уверенность успеха. Но есть ли на рынке предприятия, которые длительное время удерживаются в «слепом» режиме управления?

Если уйти от аллегории, то «скрученные спагетти» в масштабах предприятия это:

• Невозможность анализировать себестоимость продукции. Даже если система учёта ведётся с пономенклатурной детализацией, то эти цифры не имеют никакой адекватности. Следовательно, прибыль может быть самопроизвольным процессом, который не зависит от действий руководства и работников.
• Отсутствие оперативного состояния, а это отсутствие ответов на вопросы:
  • В какой стадии находятся заказы (клиента, на производство, на сборку)?
  • Чем занят штатный персонал?
  • Какая производительность организации? и др.

• Отсутствие фактических значений материальных запасов, НЗП и готовой продукции.

Доказательства из практики. Руководитель организации знает, что в штате числится 6 технологов и 4 сотрудника в отделе контроля качества. Если разделить общий объём работы на указанных сотрудников, то получаются адекватные нагрузки. После обследования выяснилось, что 2 технолога и 1 контролёр занимаются исключительно низкомаржинальной продукцией. Про малую прибыль данного вида производства знают экономисты и руководство, но они не знают разделение труда в подразделениях. В совокупности затрат на оплату труда персонала, производственных и общепроизводственных затрат результат для категории продукции оказался убыточный.

Возможно это демпинг по вытеснению конкурентов, но руководство этого не знает

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

Минимальный результат исследования:

1. Классификация бизнес-процессов организации
2. Описание каждого целевого БП в текстовом виде и блок-схеме.

Самый простой и рабочий вариант классификации:

Обследование бизнес-процессов

Прямой метод

Прямой метод соответствует со-направленному исследованию процессов и порядку процедур в деятельности.

В данном случае необходимо найти внешнее воздействие для активации процесса. Для абсолютного большинства предприятий это заказ клиента (в виде звонка, письма, план-графика). В более редких случаях (инвестиционных) — это решение владельца процесса. Например, строительство торгового центра, где отсутствует внешнее воздействие, а решение основано только на бизнес-плане проекта.

Первый событием, оно же начало процесса, на нашем примере является заказ клиента.

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

Обратный метод

Особенностью метода является изучение результата операции (бумажного или электронного документа, файла или события) и поиском автора документа. Далее определяется кто и зачем сформулировал эту потребность. Цикл этих действий определяет БП в обратном порядке.

Например, конечным пунктом деятельности по продаже продукции является передача водителю заказчика «Универсального передаточного документа», ТТН, Материального пропуска. Они созданы в программе 1С ERP менеджером по продажам для отпуска продукции. Сигналом для их оформления служит событие оплаты заказа клиента. И т.д.

Как и в предыдущем примере составляются описания процесса в анкете интервьюирования.

Смешанное использование

Стоит заметить, что прямой и обратный метод можно использовать одновременно. Это допустимо и рекомендовано в обследовании сложных процессов, к которым трудно подойти с одной стороны, либо в командном исследовании (2 человека на один БП).

Разветвление и объединение бизнес-процессов

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

Это пример реального сквозного БП, затрагивающий несколько подразделений предприятия.

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

Получили классификацию, описание и блок-схему — что делать?

Отвечаем:

1. Добавляет ли ценность продукту данная операция БП?
2. Готов ваш клиент оплачивать данную процедуру?
3. Оптимально ли движутся ресурсы предприятия? Нужно ли это движение?
4. Какие каналы связи самые длинные и почему? Для чего они нужны?
5. Передача информации между сотрудниками — это потеря во времени и в затратах. Есть излишние каналы связи?
6. Где и почему происходит больше всего брака, издержек, длительных ожиданий?
7. Чем регламентируется операция БП, каков её стандарт?

+100 вопросов…

Сергей Куканов

Что такое предпроектное обследование

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

Под предпроектным обследованием обычно понимают изучение бизнес-процессов предприятия, на котором необходимо провести автоматизацию. В процессе анализируется то, что есть на данный момент, а полученные данные позволяют наметить объем предстоящих работ.

Задача предпроектного обследования

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

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

Важность предпроектного обследования для Заказчика

Для Заказчика проведение предпроектного обследования дает возможность:

· получить подробное описание существующих на предприятии бизнес-процессов;

· оценить степень соответствия функциональных возможностей предлагаемой системы существующим бизнес-процессам;

· уточнить бюджет и сроки реализации проекта автоматизации до инициации проекта;

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

· оценить ресурсы, необходимые для внедрения системы и заранее спланировать возможность выделения этих ресурсов;

· оценить возможные риски, которые могут повлиять на работу предприятия;

· оценить возможность выполнения части работы по внедрению собственными силами для экономии бюджета.

Важность предпроектного обследования для Исполнителя

Для Исполнителя предпроектное обследование дает возможность:

· уточнить реальные ожидания Заказчика и привести их в соответствие с реальным функционалом внедряемой системы до инициации проекта;

· уточнить сроки внедрения системы и количество ресурсов, необходимых для реализации проекта;

· выявить все особенности бизнеса Заказчика, чтобы учесть их при конфигурировании системы;

· уменьшить риск выполнения незапланированных работ;

· определить и минимизировать вероятные риски, которые могут повлиять на качество и сроки внедрения;

· получение данные, необходимые для обоснования количества лицензий и структуры проекта;

· установить контакт с исполнителями со стороны Заказчика, что в дальнейшем послужит эффективной совместной работе в ходе внедрения.

Что можно узнать в результате проведения предпроектного обследования

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

· описание и оценка существующих бизнес-процессов заказчика;

· список основных задач, которые предполагается решить с помощью автоматизации компании;

· уникальные особенности бизнеса заказчика, которые нужно учесть при внедрении системы;

· описание системы документооборота на предприятии;

· оценка возможных рисков при реализации проекта с указанием возможных мер по минимизации данных рисков;

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

· количество рабочих мест, подлежащих автоматизации;

· предполагаемый бюджет проекта.

Как научиться правильно проводить предпроектное обследование

Для того, чтобы научиться правильно проводить предпроектное обследование, нужно учиться у профессионалов с большим практическим опытом в данной сфере.

20 декабря в 12:00 МСК CORS Academy будет проводить вебинар-практикум «Технологии предпроектного обследования», на котором будут разбираться различные подходы к проведению предпроектного обследования, достоинства и недостатки каждого подхода, технологии проведения и многое другое, при этом весь материал будет представлен на примере реальных кейсов.

Для кого будет полезен вебинар-практикум

• руководителей IT проектов;

• IT аналитиков;

• руководителей IT компаний и подразделений;

• менеджеров по продаже IT проектов.

Спикеры вебинара-практикума

• Илья Отькало, CEO, owner CORS Academy, автор Курса аналитика 1С https://cors.su/kurs-analitika-1c, а также десятков других курсов и тренингов, профессиональный опыт которого включает работу в 1С:Архитектор бизнеса – экс-директором по внедрению, Первый БИТ – экс-директором по внедрению компании, десятки консалтинговых проектов: WiseAdwice, Раздолье, Zerde, AKBIZ, Икс-Игрек-Зет, ПроСистемы, Интеграти, АльтСофт, Центрсофт, и другие.

• Максим Кантарович, методолог-архитектор IT-проектов, эксперт, консультант, архитектор информационных систем управления холдинговыми структурами, обладатель множества сертификатов и дипломов, в т.ч: ISO 9001, 14001, 18001, balanced scorecard (ССП), МСФО, УУ, линейка финансовых систем на платформе 1С, автор статей, семинаров, тренингов, преподаватель в ВУЗах, в т.ч MBA.

• Иван Царьков, руководитель группы Кодерлайн Софт-портал, имеет богатый опыт работы программистом, консультантом, руководителем проектов и специалистом в отделе продаж; с 2008 занимается внедрением программ1С:Предприятие, а с 2019г. занимается проведением предпроектных обследований.

Программа вебинара

В программе вебинара-практикума:

• Часть I. Введение. ГОСТы.

• Часть II. Типизация, технологии и результаты проведения предпроектных обследований;

• Часть III. Опыт предпроектных обследований перед внедрением новых систем на средних и небольших предприятиях.

Что разберем на вебинаре:

• Как правильно типизировать предприятия, чтобы выбрать наиболее подходящий тип предпроектного обследования;

• Различия в технологиях обследования в зависимости от размеров предприятий;

• Последовательность исполнения обследования;

• Реальные кейсы предпроектных обследований;

• Данные, которые важно собрать до проведения интервью;

• Что нужно выяснить на интервью;

• Как не наступить на «грабли», которые вас ожидают на каждом этапе;

• Примеры и шаблоны документов.

При этом, приобретя тариф «Профессиональный», вы получите не только шаблоны и образцы десятков документов, которые используют эксперты в своей работе, но и запись вебинара.

Как правильно провести предпроектное обследование

Под предпроектным обследованием обычно понимают изучение бизнес-процессов предприятия, на котором необходимо провести автоматизацию. В процессе анализируется то, что есть на данный момент, а полученные данные позволяют наметить объем предстоящих работ.

Для того, чтобы научиться правильно проводить предпроектное обследование, нужно учиться у профессионалов с большим практическим опытом в данной сфере.

20 декабря в 12:00 МСК CORS Academy будет проводить вебинар-практикум «Технологии предпроектного обследования», на котором будут разбираться различные подходы к проведению предпроектного обследования, достоинства и недостатки каждого подхода, технологии проведения и многое другое, при этом весь материал будет представлен на примере реальных кейсов.

Статья рассматривает алгоритм обследования бизнес процессов для дальнейшей их автоматизации (Карта автоматизации). Карта автоматизации предлагает шаги по обследованию процессов, которые включают также выбор инструментов автоматизации, SAP ERP RPA, AI. В статье разобран практический пример.

Оглавление

1. Преамбула

2. Аннотация

3. Карта автоматизации

3.1 Виды автоматизации

3.2 Препосылки  и проблемы автоматизации

3.3 Предлагаемая карта автоматизации

3.3.1 Уровень портфолио

3.3.2 Уровень проекта

3.3.3 Поддержка

4. Прочие советы и рекомендации

1. Преамбула

Статья рассматривает алгоритм обследования бизнес процессов для дальнейшей их автоматизации (Карта автоматизации). Карта автоматизации предлагает шаги по обследованию процессов, которые включают также выбор инструментов автоматизации, SAP ERP RPA, AI. В статье разобран практический пример.

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

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

Для понимания текста требуется знание модуля финансы SAP ERP, основного определения RPA (robotic process automation) .

2. Аннотация

В статье на практическом примере рассматриваются:

—  карта автоматизации: вопросники, алгоритм принятия решения по автоматизации;

— бизнес кейсы двух процессов: один – внедрение SAP, другой внедрение роботизированного решения RPA.

3. Карта автоматизации

Назначение карты автоматизации  – обеспечить детальное обследование бизнес процесса на предмет его зрелости, а также выбор инструментов автоматизации, саму автоматизацию, модель поддержки.

Вопросы, на которые должна помочь ответить карта автоматизации:

— Достаточно ли стабилен и зрел бизнес процесс?

— Требуется ли автоматизировать бизнес процесс?

— Какую технологию выбрать для автоматизации?

3.1 Виды автоматизации

Справка (Википедия):

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

Автоматизация позволяет повысить производительность труда, улучшить качество продукции, оптимизировать процессы управления, автоматизация требует комплексного, системного подхода к решению задачи.»

Любой рутинный процесс, который стабилен (не меняется в зависимости от воли человека), последователен (может быть описан с помощью последовательности шагов), выполняется по расписанию и занимается много времени для выполнения, может и должен быть автоматизирован. На схеме (Рис.1.) отображены виды автоматизации.

Рис.1. Виды автоматизации

На данный момент выделяют следующие виды автоматизации:

1. Процессная (Делать) – связана с оптимизацией текущих процессов:

• Приложения (apps – от англ applications(приложение) – в случае если весь бизнес процесс ведется в одном приложении, есть смысл рассмотреть модели автоматизации внутри этого приложения. Например, запланировать шаги выполнения задачи в SAP в фоновом режиме в определнном порядке и временных интервалах; другой пример – макрос в Excel.
• RPA — в случае если процесс ведется в нескольких приложениях сразу (есть также ряд других условий) можно внедрить технологии RPA (роботы), выделяют 2 вида RPA: процесс выполняется роботом, но с участием человека (подтверждения, инициация выполнения), без вмешательства человека (Робот действует самостоятельно).

Справка (Википедия):

«RPA в традиционных системах автоматизации документооборота: разработчик программного обеспечения создает список действий для автоматизации задачи и взаимодействия с внутренней системой с использованием внутренних интерфейсов прикладного программирования (API) или выделенного языка сценариев. Напротив, RPA-системы разрабатывают список действий, наблюдая за тем, как пользователь выполняет эту задачу в графическом пользовательском интерфейсе приложения (GUI), а затем выполняет автоматизацию, повторяя эти задачи непосредственно в графическом интерфейсе. Это может снизить барьер для использования автоматизации в продуктах, которые в противном случае не могли бы использовать API для этой цели.»

2. Анализ и предсказание результата (Думать) – анализ существующих данных, выявление паттернов поведения и предсказание результатов, основываясь на статистических выкладках и алгоритмах:

• Машинное обучение — самообучаемые алгоритмы анализа данных.

Справка (Википедия):

«Машинное обучение (англ. machine learning, ML) — класс методов искусственного интеллекта, характерной чертой которых является не прямое решение задачи, а обучение в процессе применения решений множества сходных задач. Для построения таких методов используются средства математической статистики, численных методов, методов оптимизации, теории вероятностей, теории графов, различные техники работы с данными в цифровой форме.»

Различают два типа обучения:

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

• Искусственный интеллект – в данном контексте чат боты, личные ассистенты, виртуальные собеседники.

3.2 Предпосылки  и проблемы автоматизации

При построении карты автоматизации должны быть учтены следующие пункты, указанные на рисунке 2.

Рис.2. Проблемы автоматизации

Проблемы, которые могут возникнуть в противном случае:

— Стабильность и учет исключений: бухгалтерское закрытие, робот который делает проводки начислений (5000 документов за час) вдруг остановился, анализ показал, что требуется срочно внести изменения в код – согласно регламенту изменения в код должны быть согласованы с главным программистом, архитектором, протестированы и так далее. В итоге – задержка закрытия.

— Анализ процесса – операционист описал по шагам бизнес процесс, команда автоматизации внедрила робота, немного позднее архитектор решения SAP проанализировал задачу и сказал, что быстрее и дешевле было бы оптимизировать процесс внутри SAP без внедрения робота.

— Вовлеченность – группа по правам и полномочиям в SAP получает запрос на создание юзера с правами ведения основной записи поставщика и при этом еще и платежей поставщику. Проект заморожен, так как согласно внутренней политике компании – это нарушение безопасности (Робот может изменить банковский счет поставщика и повести оплату на этой счет).

3.3 Предлагаемая карта автоматизации

Рис.3. Карта автоматизации

3.3.1 Уровень портфолио

Задача

• Представить карту автоматизации всем сотрудникам
• Представить виды автоматизации и объяснить разницу

Действия

• Организовать совещание для всех сотрудников и продемонстрировать презентацию, с пояснением, в каких конкретно случаях

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

1.1. Обследование общих закономерностей функционирования организации.

1.1.1. Цель этапа.

Зафиксировать (идентифицировать) структуру организации и общие закономерности ее деятельности.

1.1.2. Содержание работ.

1.1.2.1. Запрос документов регламентирующих деятельность организации в целом.

Более эффективным запрос может быть если сотрудникам заказчика будет передан “Список областей деятельности” по которым требуется регламентирующие документы.

Общие закономерности для построения такого списка:

• документы, определяющие функционирование организации в целом;
• документы, определяющие направления ее деятельности;
• документы, определяющие правила и принципы осуществления стратегического управления;
• стратегический план (план развития) организации.

1.1.3. Результат.

1.1.3.1. Систематизация информации.

Результатом систематизации информации полученной из регламентирующих документов должен стать отчет отражающий:

• Общие принципы функционирования организации.
• Структуру подразделений.
• Направления деятельности.
• Правила взаимодействия компании с внешними организациями.
• Основные бизнес-процессы.

1.2. Обследование деятельности каждого автоматизируемого подразделения.

1.2.1. Цель этапа.

Выявить общую картину структуры бизнес-процессов организации, зафиксировать функции подразделений.

1.2.2. Содержание работ.

1.2.2.1. Предварительный запрос информации о функционировании подразделений.

Цель шага заключается в подготовке сотрудников организации к процессу обследования бизнес-процессов подразделений и структурировать основной объем информации связанный с общими условиями их функционирования. Запрос может проводиться высылкой в организацию запросных форм, где они должны быть выданы ключевым сотрудникам подразделений бизнес-процессы, которых автоматизируются. Или собственным заполнением форм путем проведения интервьюирования. Запросные формы должны содержать следующие вопросы в приведенной последовательности.

1. Название подразделения.
2. Какие документы определяют условия общей работы подразделения и выполнение конкретных функций (регламенты, должностные инструкции, кодексы и т.п.).
3. Какие функции выполняет подразделение.
4. Какие документы, отчеты из других подразделений, справки, заказы, заявки и т.п. поступающие в подразделение, необходимы для его работы.
5. Какие документы, отчеты, справки, заказы, заявки и т.п. появляются в результате работы подразделения, которые далее архивируются, передаются в другие подразделения, поставщикам клиентам и т.д.

Примечание. Форма запроса данных приведена в приложении 1.

1.2.2.2. Составление отчета.

Полученные данные о функционировании подразделений должны быть систематизированы и представлены в обобщающем отчете по этапу, который должен содержать следующие разделы:

1. Структура организации.
2. Общий перечень бизнес-процессов организации.
3. Описания деятельности подразделений:
   1. название подразделения;
   2. документы регламентирующие деятельность;
   3. выполняемые функции;
   4. входящие документы;
   5. исходящие документы;
   6. ревизия имеющихся организационных документов;
   7. результаты деятельности подразделения

1.2.2.3. Подготовка положения о классификации бизнес-процессов.

Положение о классификации бизнес-процессов (далее Положение) отражает верхний уровень деления бизнес-процессов.

Все бизнес-процессы организации классифицируются на основные, обеспечивающие, развития, управления.

Основные бизнес-процессы< непосредственно ориентированы на производство продукции, представляющие ценность для клиента и обеспечивающие получение дохода для предприятия.

Обеспечивающие бизнес-процессы – вспомогательные бизнес-процессы, которые предназначены для обеспечения выполнения основных процессов. Фактически обеспечивающие бизнес-процессы снабжают ресурсами всю деятельность организации.

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

Бизнес-процессы развития – процессы совершенствования, освоения новых направлений и технологий, а также инновации.

В положении приводится полная классификация всех выделенных бизнес-процессов организации, разнесением их в 4 раздела.

1. Основные бизнес-процессы.
2. Обеспечивающие бизнес-процессы.
3. Бизнес-процессы управления
4. Бизнес-процессы развития.

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

1.2.2.4. Уточнение полученной информации о функционировании подразделений.

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

Результаты выполнения этапа должны быть внесены в отчет построенный по структуре приведенной в пункте 1.2.2.

1.2.3. Результат.

Отчет о деятельности подразделений построенный по форме приведенной в пункте 1.2.2.2.

Положение о классификации бизнес-процессов, систематизирующее информацию о бизнес-процессах.

1.3. Детальное обследование бизнес-процессов.

1.3.1. Цель этапа.

Зафиксировать необходимые детали выполнения бизнес-процессов.

1.3.2. Содержание работ.

1.3.2.1. Запрос данных о выполнении бизнес-процессов.

Запрос данных производится у владельца процесса в виде интервью по каждому бизнес-процессу с использованием формы приведенной в приложении 2. Последовательность действий выполнения бизнес-процессов (пункт 10 запросной формы) фиксируются на отдельном листе.

1.3.2.2. Подготовка положений о выполнении бизнес-процессов.

В положениях приводится полученная информация, описывающая выполнение бизнес-процессов в следующей форме:

1. Название бизнес-процесса.
2. Условия начала выполнения бизнес-процесса.
3. Документы и данные, необходимые для выполнения бизнес-процесса и их источники.
4. Документы создаваемые в результате выполнения бизнес-процесса и их получатели.
5. Действующие лица принимающие участие в выполнении бизнес-процесса.
6. Материальные ценности необходимые для выполнения бизнес-процесса, если таковые есть.
7. Материальные ценности – результат выполнения бизнес-процесса, если таковые есть.
8. Результаты выполнения бизнес-процесса (кроме вошедших в п.7).
9. Цель данного бизнес-процесса, его место и роль в общих задачах (процессах) компании.
10. Проблемы, возникающие при выполнении бизнес-процесса.
11. Нештатное завершение (выполнение) бизнес-процесса.
12. Последовательность действий выполнения бизнес-процесса.

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

1.3.2.3. Документирование бизнес-процессов.

Документы:

• формы
• схемы
• записи
• устные высказывания

Средства документирования (фиксации информации):

• схема организационной структуры (необходима для понимания структуры организации; описывает формальные отношения между отделами – иерархические и функциональные)
• принципиальная схема бизнес-процесса (схематическое изображение основных элементов бизнес-процесса)
• иерархическая схема бизнес-процессов (понимание структуры и связей во всей системе)
• общий обзор процессов и схема подразделения (описание модели отношений в рамках данного процесса, включая подразделения, конкретных специалистов)
• общая схема процесса (описание компонентов, входящих в бизнес-процесс – основа для последующей маршрутизации)
• детальная схема процесса (последовательность рабочих инструкций и каналов движения документов “UML”)
• схема инструкций (предназначена для сотрудников организации – что должны выполнять и каким правилам следовать)
• схема управления формами (использование и маршрутизация форм/документов/ в рамках бизнес-процесса – детальное представление действий для каждой формы в хронологическом порядке)
• схема обращения форм (поток форм/документов/ в соответствии со структурными единицами и отделами)
• бухгалтерская диаграмма (дает представление о системе обработки данных бухгалтерского учета компании)

1.3.2.4. Уточнение зафиксированной последовательности выполнения бизнес-процессов.

Формализованные данные о последовательности выполнения бизнес-процессов, с указанием соответствующего ему документооборота должны быть согласованы с сотрудниками заказчика. Согласование должно проводится в виде интервью с возможным предварительным представлением материалов по почте.

Полученные уточнения должны быть внесены в описание бизнес-процессов, после чего согласование должно повториться.

1.3.3. Результат.

Положения по бизнес-процессам.

Положение по “родительскому” бизнес-процессу.

Положение по документообороту.

Положение по деятельности Организации.

2. Моделирование.

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

Моделирование бизнес-процессов организации включает два этапа структурное и детальное.

Структурное моделирование бизнес-процессов организации может выполняться в нотации IDEF0 с использованием инструментария BPwin или на языке UML с использованием инструментария Rational Rose.

Детальное моделирование выполняется на языке UML.

2.1.1. Структурное моделирование.

На этапе структурного моделирования в модели должны быть отражены:

• существующая организационная структура;
• документы и иные сущности используемые при исполнении моделируемых бизнес-процессов и необходимые для моделирования документооборота, с описаниями их основного смысла;
• структуру бизнес-процессов, отражающую их иерархию от более общих групп к частным бизнес-процессам;
• диаграммы взаимодействия для конечных бизнес-процессов, отражающие последовательность создания и перемещения документов (данных, материалов, ресурсов и т.п.) между действующими лицами.

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

2.1.2. Детальное моделирование бизнес-процессов.

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

Детальная модель бизнес-процесса должна включать:

• набор прецедентов отражающих возможные варианты выполнения бизнес-процессов “как есть”;
• диаграммы действий, детально описывающие последовательность выполнения бизнес-процессов;
• диаграммы взаимодействия, отражающие схемы документооборота.

Модели должны быть согласованы с ведущими специалистами организации обладающими необходимыми знаниями.

В случае если после построения моделей согласование не было достигнуто ” в модель должны быть внесены необходимые уточнения и коррективы. Процесс итерации (согласование, внесение корректив и уточнений) должен повторяться до момента полного подтверждения, что модель понятна и однозначно представляет детали бизнес-процессов.

Приложение 1. Форма запроса данных об общей деятельности организации.

Форма передается для заполнения руководителям подразделений.

Заполнение может выполняться в свободной форме на отдельном листе.

1. Название подразделения.
2. Какие документы определяют условия общей работы подразделения и выполнение конкретных функций (регламенты, должностные инструкции, кодексы и т.п.).
3. Какие функции выполняет подразделение (с указанием ответственных).
4. Какие документы, отчеты из других подразделений, справки, заказы, заявки и т.п. поступающие в подразделение, необходимы для его работы.
5. Какие документы, отчеты, справки, заказы, заявки и т.п. появляются в результате работы подразделения, которые далее архивируются, передаются в другие подразделения, поставщикам клиентам и т.д.

Приложение 2. Форма запроса данных о выполнении бизнес-процессов подразделениями.

1. Название функции:	1. Первоначальные данные или информация, с поступления которых начинается выполнение функции:
2. Документы, отчеты, запросы, справки и т.п. необходимые для выполнения функции. Их источники:
3. Документы, отчеты, справки, формируемые при выполнении функции. Их получатели:
4. Сотрудники организации, а также клиенты, поставщики и иные внешние организации, участвующие в выполнении функции:
5. Материалы и другие материальные ценности, необходимые и потребляемые при выполнении функции:
6. Материалы и другие материальные ценности, получаемые в результате выполнения функции:
7. Степень важности процесса в рамках работы подразделения (А ” очень важный, В ” средней важности, С ” практически неважный)
8. Возникают ли проблемы при выполнении процесса” И если да то каковы они: насколько критичны: кардинально влияют на общую деятельность компании/влияют на функционирование отдела/не значительны, зависят от работы: сотрудников/смежных подразделений/ поставщиков/клиентов, неблагоприятно влияют на: стоимость/время/качество выполнения процесса.
9. Время выполнения процесса:
10. Последовательность действий выполнения процесса.

Приложение 3. Структуры документов, содержащих результаты обследования

Система кодирования и регистрации документов:

• дата и имя составителя
• код документа (проект/тема/номер документа в теме/номер версии)
• регистрационный файл документов проекта

Состав документов Положения по документообороту

Схема документооборота

Номер документа (код)	Наименование документа	Откуда приходит/ исходит документ	Куда уходит	Информация, документы, используемые при формировании документа	Операции, выполняемые над документом	Ответственный за выполнение операций над документом

Табель документооборота

Номер документа	Наименование документа	Тип документа	Частота документа за временной период	Ответственный за документ (сотрудник или отдел)
		Внутренний/внешний; Входящий/исходящий; транзитный

Альбом форм документов

Номер формы	Наименование формы (классы документов)	Поля формы	Обязательные для заполнения поля	Типовая форма (ссылки на образец и шаблон)

Таблица соответствия форм и документов

Номер формы	Наименование формы	Код документа

Графическая схема документооборота

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

Состав документов Положения по управлению

Должностная инструкция

Организационная единица
Должность
Бизнес-процесс
Функциональные обязанности	Входящие документы и информация (где берется/находится)	Исходящие документы и информация (куда направляется)
Бизнес-процесс
Функциональные обязанности	Входящие документы и информация (где берется/находится)	Исходящие документы и информация (куда направляется)

Положение по структурному подразделению (данные для разработки)

Номер документа	Наименование документа	Тип документа	Частота появления документа

Код бизнес-процесса	Основные задачи	Взаимодействие (коды структур. подразделений)	Способ взаимодействия	Коды входящих и исходящих документов	Администр. подчиненность (осуществляет контроль)

Матрица процесс-отдел

	Процесс 1	Процесс #
Отдел 1	(коды подпроцессов, относящихся к данному отделу/подотделу)
Отдел #

Положение по организационной структуре

Графическое представление оргструктуры.

• составляется в свободной форме
• должно быть удобочитаемой
• размещаться на бумаге стандартного размера
• адаптирована к уровню знаний читателя
• дает представление о структурных подразделениях и их взаимосвязи
• позволяет ввести нумерацию структурных подразделений (кодирование)

Название структурного подразделения	Руководитель	Административная подчиненность (непосредственный вышестоящ. линейный начальник)	Функциональная подчиненность

Состав документов Регламент бизнес-процессов

Принципиальная схема бизнес-процесса (графич.)

• составляется в свободной форме
• должно быть удобочитаемой
• размещаться на бумаге стандартного размера
• адаптирована к уровню знаний читателя

Иерархическая схема бизнес-процессов (графич.)

• основа для описания бизнес-процесса
• вводит нумерацию бизнес-процессов
• (составляется в стандарте IDEF0)

Вовлеченность отделов в бизнес процесс (составляется для каждого бизнес-процесса)

	Отдел 1	Отдел #
Подпроцесс 1	(коды вовлечености)
Подпроцесс #

Возможные коды:

Коды принадлежности:

• инициирует
• выполняет
• владеет

Коды для управления:

• управляет
• выполняет
• контролирует
• обслуживает
• информирует

Контроль

Процесс номер	Отдел номер	Описание процесса	Описание контроля

Детальная схема бизнес-процесса

Составляется в соответствии с нотацией IDEF0 и/или UML

Представляет собой последовательность рабочих инструкций и каналов движения документов.

Система показателей эффективности бизнес-процесса

Код бизнес-процесса	Наименование показателя эффективности бизнес-процесса	Предварительный (возможный, допустимый) диапазон изменения показателя эффективности бизнес процесса)	Формула для расчета (способ получения показателя)	Документы, используемые для формирования показателей эффективности бизнес-процесса

Возможности для улучшения бизнес-процессов

Код процесса	Цель	Приоритет	Дополнительная информация, необходимая для анализа

Классификации бизнес-процессов

По уровню иерархии:

• Базовые бизнес-процессы – бизнес-процессы первого уровня, дальнейшая композиция которых возможна лишь в терминах “бизнес Компании в целом”
• Подпроцессы (функции) – бизнес-процессы, которые могут быть подвергнуты композиции

По вкладу в создание основной стоимости:

• Основные – бизнес-процессы, в рамках которых создается добавленная стоимость (конечная или промежуточная) для продукта, входящего в портфель бизнесов Компании
• Вспомогательные – бизнес-процессы, поддерживающие основную деятельность Компании, направленные на интеграцию Компании как единого организма

Характеристики бизнес-процесса

• Входящий массив данных (информация, документы и т.п.) и ресурсов (материальные и нематериальные активы)
• “Продукт на выходе”: что является результатом бизнес-процесса
• “Хозяин” бизнес-процесса: объект (компания, подразделение, сотрудник), отвечающий за данный бизнес-процесс
• Ресурсы (материальные и нематериальные активы, кадровые ресурсы), задействованные в реализация процесса
• Контрольные показатели эффективности бизнес-процесса
• Механизм реализации

Бизнес-процессы (общие сведения)

• Основная цель бизнес-процесса ” преобразование входа (входящих в процесс ресурсов, необходимых для реализации процесса) в выход, т.е. результат, продукцию процесса.
• Основной “начинкой” бизнес-процесса является совокупность подпроцессов, работ, операций, осуществляемых над входами для получения выходов. Процесс осуществляется с помощью определенного механизма
• Существуют первичные и вторичные входы процесса. Первичные входы поступают на начало процесса. Вторичные входы появляются в ходе реализации процесса на составляющих его подпроцессах.
• Первичные выход ” это прямой, запланированный результат реализации процесса. Вторичный выход ” это побочный продукт процесса, не являющийся его главной целью.
• Процесс происходит на сам по себе, он управляется и производится конкретным исполнителем или группой.
• Бизнес-процесс производится для кого-то ” тот, кто потребляет результат процесса, является клиентом процесса.

Качественные параметры бизнес-процесса

• Результативность – описывает соотношение полученного результата и того, чего хотят или ожидают заказчики.
• Эффективность – показывает, как хорошо выполняются процессы.
• Адаптируемость – свидетельствует о том, насколько хорошо процесс способен реагировать на изменения в окружающей среде.
• Производительность ” отношение количества единиц на выходе к количеству единиц на входе.
• Длительность ” время, которое необходимо для выполнения процесса, или промежуток времени между началом процесса и его завершением.
• Стоимость процесса ” это совокупность всех затрат в денежном исчислении, которые необходимо произвести для однократного выполнения процесса.

Бизнес-процессы Компании (организации)

1. Бизнес-процессы развития и совершенствования
2. Бизнес-процессы ведения основной деятельности
3. Бизнес-процессы вспомогательные

Автор: А.И.Кузнецов

Когда обдумывал содержание данной статьи, изначально я хотел описать алгоритм самостоятельного проведения экспресс-обследования перед автоматизацией. Все для того, чтобы качество и эффективность проектов внедрения информационных систем у российских производителей продуктов питания вышло на новый уровень. (Не секрет, что не все хотят привлекать кого-то со стороны для проведения предпроектной оценки). Не получилось)) Понял, что такие работы должны выполнять специалисты и, наоборот, не надо их делать самостоятельно (это спойлер, детали внутри). Ибо это подобно самодиагностике вместо обращения к врачу. Готовы рисковать здоровьем и экспериментировать с собой? А со своим бизнесом?

Итак, сегодня в статье — кому и зачем нужно 2-х дневное экспресс-обследование перед автоматизацией? как оно проходит? что дает? Дополнительно напишу стандартные «грабли», на которые наступает большое количество компаний, которые надумали автоматизироваться.

Сразу предупреждаю — буков много. Кто не любит читать – можно
пробежать «по диагонали», суть тоже поймете.

ЧТО ЗА
ХУРМА?

Итак, по какой-то причине вы задумались об автоматизации своего предприятия. Кто-то – в свете предстоящей отмены в 2022 году поддержки отраслевых решений на УПП. Кто-то готовится к внедрению маркировки под «Честный знак». Кто-то хочет автоматизировать оперативный учет на производстве и складах готовой продукции, чтобы соответствовать будущему ужесточению требований со стороны «Меркурия». А есть и такие, кто хочет просто навести порядок на своем производстве и сделать работу своего предприятия более эффективной и управляемой. Да-да, есть и такие – кто автоматизируется не под давлением внешних обстоятельств, а по собственному желанию))

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

Во время данных двух дней мы получаем ответы на следующие вопросы:

• Для решения каких проблем/задач нужен проект
  автоматизации?
• Какими должны быть ключевые результаты проекта?
• Какие процессы должны попасть в проект
  автоматизации?
• Какой функционал нужен в автоматизированной
  системе?
• Какой и почему должна быть целевая архитектура программного
  обеспечения?
• Каким набором задач и в какой очередности
  необходимо выполнять проект внедрения? Почему именно так?
• Какие задачи нужно делать в проекте собственными
  силами, а какие лучше отдать на выполнение сторонним компаниям?

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

ДЕЛАЙ РАЗ,
ДЕЛАЙ ДВА…

Теперь про то – как проводим экспресс-обследование
и как укладываемся в 2 дня.

1 день

Активный сбор информации с бизнес-потребителей, функциональных руководителей и ключевых пользователей системы относительно

• проблем/ задач, которые должна решать система,
• необходимого им функционала.

// При этом важно понимать, что профессиональных постановщиков задач крайне немного и многие люди начинают фантазировать, если не знают ответа на вопрос «что и для чего хотите?» Поэтому наши специалисты, пропуская полученную информацию через фильтр своего опыта,

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

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

2 день

Собранная за прошлый день информация анализируется для
выстраивания «картинки»:

• какие проблемы/задачи из выявленных важны для решения в первую очередь и почему

// что больше, а что меньше может принести ущерб или дополнительный профит бизнесу

• целевой ИТ-ландшафт

// на какой конфигурации или
наборе конфигураций программных продуктов лучше делать такие задачи, чтобы
сохранить разумными затраты на внедрение и (что не менее важно) на дальнейшее
сопровождение и развитие системы. Например, кому-то вполне можно будет обойтись
отраслевой версией «1С:ERP», а
кому-то лучше вынести финансовый контур отдельно от баз по управлению
производством и складами.

• какими этапами и почему именно так надо идти к целевой системе

// надо учитывать – как
блоки информационной системы связаны между собой и как их внедрять, чтобы не
делать повторных телодвижений по переделыванию своей работы

• что можно сделать самостоятельно силами своих ИТ-ков, а что лучше отдать на исполнение сторонним специалистам

// можно искренне верить во
всесильность своих ИТ-ков, но чаще всего они просто обычные люди

• как эти этапы должны накладываться на график, чтобы получить интересующий результат

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

• сколько может стоить проект внедрения интересующей системы именно на этом предприятии

// и руководству компании, и собственникам всегда хочется опираться на реальную оценку, чтобы планировать свой бюджет. Бывает, что обозначенная сумма вызывает реакцию «мы на такое не рассчитывали!» ))) Просто мы считаем, что лучше на входе понять реальный масштаб проблемы, чем соблазниться на небольшой бюджет «со звездочкой», а потом выложить в несколько раз больше для доведения до необходимого результата

После такого «мозгового штурм» формируется клиентский документ для обсуждения полученной «картинки» с ключевыми сотрудниками на стороне предприятия. Существенно помогает в этом опыт выполнения проектов внедрения учетных систем на множестве пищевых производств.

Стоит упомянуть, что детальность такого обследования в силу
кратковременности будет существенно отличаться от серьезной и детальной проработки
технического задания. Как концепт здания архитектора от строительных чертежей.
Но это гораздо лучше, чем просто вера в успех и русский авось (см. про грабли
ниже по тексту).

ЧТО МОГУТ
ДАТЬ 2 ДНЯ?

Что в сухом остатке получает клиент и мы по итогам проведенного
экспресс-обследования?

Клиент – выдержку опыта с пониманием вектора «куда и как» идти + оценку проекта в сроках-деньгах. Попутно во время общения с нашими специалистами происходит информационное обогащение на тему решения интересующих проблем/задач («а как у других это делается?») Такая информация многого стоит и дает возможность не совершать лишних телодвижений. А еще можно позадавать другие вопросы из смежных областей, которые не давали покоя и заставляли тратить время и нервы. Не факт, что с ходу дадим ответы )) Хотя, чаще вопросы задают не уникальные и можно сразу поделиться опытом.

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

В общем экспресс-обследование – это те самые 2 дня, которые месяц
экономят.

РАЗНЫЕ
ЕСТЬ ГРАБЛИ. А ЕСТЬ МОИ, ЛЮБИМЫЕ.

• Поручить своим ИТ-кам

// Регулярно случается, что разобраться и начертить «дорожную карту» проекта просят своих ИТ-ков. Заказчик разумно полагает, что раз это проект автоматизации на «1С», то именно им рисовать план внедрения и заниматься отбором ПО/ интеграторов. Серьезно? Ребята из ИТ должны определить – что и зачем нужно вашему бизнесу + вашим управленцам? Чаще планы по проекту автоматизации рисуются в этом случае так, чтобы потом можно было снять с себя полную ответственность, если что-то пойдет не так («мы думали в программе все уже учтено», «пользователи сказали, что нам надо, мы это и сделали», «интеграторы сделали проект как им удобно» и т.д. и т.п.)

• Заполнить анкету/ опросник

// Классика. «Мы не знаем, что вам рассказать про свои
проблемы/задачи. Может вышлете какую-то анкету?» Многие фирмы франчайзи завели
такую ритуальную анкету с разной степенью детальности вопросов. И вот тут
начинается интересное. Фактические данные заполнить не трудно (количество SKU, тонн сырья в день перерабатываем, отгрузок в
день, строчек в накладной  и т.д.) А что
делать с описанием необходимого функционала? Просто поставить галочку в строчке
с коротким названием – «адресное хранение», «партионный учет», «интеграция с
оборудованием»? И как это поможет оценить реальную глубину и сложность задачи
без визуального знакомства с объектом автоматизации и живого общения с будущими
заказчиками и пользователями системы? Там же нюансов и трактовок таких широких
терминов может быть вагон! Впрочем, если оценка проекта нужна не для реального
использования, а как формальный ритуальный шаг для получения хоть какого-то
понимания о сроках-бюджетах, то вполне сгодится. Но это не точно ))

• Купить ПО до начала проекта

// Покупка ПО перед началом проекта автоматизации видится логичным
шагом. Особенно если купить «1С:Наш комбинат», где все должно быть учтено и
продумано за нас ))) Однако, потом неловко становится. Ведь программа уже
куплена и надо бы ее использовать. А если она не подходит для решения имеющихся
проблем/задач и многого задекларированного функционала просто нет физически? А
если это выяснится не в самом начале проекта?

• Война план покажет

// Совсем пропустить этап обследований приходится в силу разных
причин многим предприятиям — времени нет, денег жалко, нет доверия к тем, кого
знаете и т.д. и т.п. Надежда на то, что все как-то само рассосется и по ходу
дела сорганизуется, может держаться разное количество времени в зависимости от
оптимистичности или загруженности заказчиков автоматизированной системы. Но
всегда наступает разочарование/ отрезвление/ обида/ злость/ мудрость
(подчеркните нужное).

• Любой 1С-к справится

// Даже если понимаем, что своим ИТ-кам не справиться и надо звать
кого-то со стороны, то всегда возникает вопрос – как выбрать консультантов со
стороны. Деньги – наиболее понятный критерий. Одни – дороже. Значит, у них
квалификация повыше (или просто жадные попались). Другие – дешевле, значит
поменьше квалификация. Чего тут не понять? Ну и, кстати, посмотрим, чтобы у них
был опыт работы с в схожей с нами отрасли. Только вот надо учитывать, что
большинство компаний в среде «1С» специализируются на решении задач, связанных
с автоматизацией бухучета. А значит поручить таким «специалистам» автоматизацию
процессов торговли и производства – это заплатить им за получение нового опыта
(будем надеяться – успешного). Я думаю, они только рады будут ))

В
ЗАВЕРШЕНИЕ

Вопрос диагностики важен не только в автоматизации, но и в других
областях профессиональных услуг (строительство, образование, медицина, спорт…)
Будьте внимательны, пожалуйста, не упускайте из внимания этот важный
непродолжительный этап.

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

Всем добра!

Что такое обследование

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

Зачем нужно обследовать процессы

Иногда встречается мнение, что «Обследование» — это бесполезный для клиента этап. «Мы то и так знаем, как мы работаем, это вы без обследования не можете нас автоматизировать».

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

   Заказчик и исполнитель идут к одной цели – успешному проекту внедрения системы. Если какое-то мероприятие нужно, чтобы повысить вероятность успеха, оно нужно обоим сторонам.

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

   Большинство компания работает «как сложилось» в ходе роста, найма новых людей, распределения функций между ними. Никто не знает, как работает компания в целом. Представление о прохождении одних и тех же процессов у собственника, у руководителей отделов и у рядовых сотрудников может быть совершенно разным.

3. В ходе обследования выявляются изменения и улучшения, которые можно сделать, не дожидаясь внедрения 1С.

   Осознание, выявление бизнес-процессов, это работа, запускающая поиск улучшений и изменений. Частая ситуация в ходе интервью «Мы что, правда так работаем? – Да. – Не может быть! – Точно так – Давайте это поменяем, мы же теряем заказы/деньги/время».

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

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

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

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

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

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

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

Пытаться выбирать и внедрять 1С, и любую другу систему управления, без обследования, всё равно что прийти к врачу и попросить сразу выписать нужное лекарство, без диагностики. Вы ведь и так знаете – вот болит спина, нужна таблетка от боли. Потому что «обследование, мне это не нужно, я за лечение плачу, а не за то чтобы вы меня обследовали».

Как проходит обследование

Как Заказчику понять, что обследование идет верно, и вы получите нужный результат?

• Начало проекта – стратап-встреча.

  Предложение начинается с большой буквы, а проект – со стартап-встречи. Это важное мероприятие, на котором происходит знакомство команды, поясняются роли, утверждается устав и план.

• Серия интервью, на них приходят аналитики с подготовленными вопросами.

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

  Обратите внимание, сессии вопросов-ответов должны идти гладко и четко. Это говорит о том, что аналитики приехали подготовленными, они не придумывают вопросы на ходу, а идут по своим опросникам, собирая в голове и в документе схему процессов.

• Состав вопросов, и ход интервью.

  Хорошо, если вопросы – понятны. Аналитики должны спрашивать вас про то, как работает ваш бизнес. А не про то, какие «галочки» в 1С им нужно поставить. Если вопросы не понятны, или относятся к настройкам 1С, например, «скажите, вы будете использовать ордерную схему на складе?» это плохой признак. Возможно перед вами не бизнес-аналитик, а 1С консультант.

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

• Финальный документ и работа по нему подрядчика и заказчика.

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

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

Что вы, как заказчик, можете сделать чтобы повысить шансы на успех проекта, и получить максимум пользы:

1. Назначьте «Руководителем проекта» со своей стороны – руководителя высокого уровня влияния в компании.

2. Сделайте так, чтобы он приходил на все интервью и встречи (освободите время, примите высокую важность проекта для компании).

3. Пусть ваш РП (или вы, если вы решили им быть) фиксирует замеченные «странности» в работе и принимает решения об их устранении.

4. РП заказчика необходимо подчеркивать важность проекта своим примером, «усмирять» сотрудников-сопротивленцев.

5. Внимательно изучайте документы от подрядчика, это подписывайте их так как «много текста, лень читать». Предложения сотрудников по документу так же проверяйте до отдачи подрядчику, если разослали документ на ознакомление.

6. Не отдавайте подрядчику противоречащие друг другу замечания, организовывайте встречи рабочей группы внутри компании, принимайте решения и отдавайте согласованные предложения/замечания/идеи. 

Результаты обследования

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

Что должно быть в результирующем документе?

1. Полный список или схема всех процессов, подлежащих автоматизации в ходе проекта. В виде картинки, схемы и/или текстового описания процессов.

2. Схемы и описание каждого бизнес-процесса.

   Какую методологию описания лучше использовать?

   Я не стал бы требовать описания процессов в IDEF0, UML, или другой нотации. Главное требование – схемы и описания процессов должны быть понятны вам, как заказчику, без дополнительного «обучения чтению диаграмм».

   Нужно ли описывать «как есть» и «как будет»?

   Есть разные подходы. Многие консультанты описывают процессы «как есть» и «как будет». Проблема описания «как есть» заключается в том, что оно почти бесполезно. В ходе встреч сразу принимаются решения, процессы могут поменяться, и «как есть» окажется слепком момента в прошлом. Мы считаем, что описывать нужно процессы «как будет» с ЗБР (зоной ближайшего развития).

   Насколько подробным должно быть описание?

   
   Каждый шаг процесса должен быть действием, имеющим конкретный результат – созданный документ, принятый на склад товар, принятое решение. Опускаться в детализации до «нажал кнопку А, посмотрел на монитор, взял в руки мышь, отодвинул кружку…» — не нужно.
   

   Нужны ли описания требований к 1С (на уровне технических заданий, или схем интерфейсов)?

   Это зависит от общей схемы проекта и согласованных между вами и подрядчиком результатов каждого этапа. Есть компании, которые в рамках одного этапа и описывают процессы, и пишут требования на доработку/настройку учетной системы. Мы в нашей практике разделяем эти этапы – исследование бизнеса это одно, а то какую 1С выбрать для решения бизнес-задач, как ее настроить, это другое. У нас это 2 разных этапа проекта, и 2 разных документа.

3. Ролевая матрица. Список или таблица ролей в компании, с указанием того в каком процессе какая роль участвует, за какой процесс какая роль отвечает. Под ролью имеется ввиду не должность. Человек на должности «коммерческий директор», может иметь и роль «КД» и роль «Продавец» и роль «HR».

4. (желательно) Список изменений, улучшений и предложений, а также задач заказчика в ходе проекта. Не каждая компания подрядчик собирает такой список, так как он не относится непосредственно к внедрению 1С. Мы его готовим для того, чтобы заказчик получил больше пользы от этапа.