CADmaster

Представим себе следующую ситуацию:

• руководство организации сформировало стратегический план развития, определило задачи и их приоритет. Предположим, что это комплексное решение (PDM, CRM, BIM, ERP или система PLM), автоматизирующее работу нескольких подразделений;
• ИТ-служба совместно со специалистами подразделений определила требования и сформировала план внедрения. После сравнения функционала, было приобретено нужное ПО.

Дальнейшие шаги, как правило, тоже стандартны:

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

Вроде все шаги правильные, но если решение затрагивает несколько подразделений и изменяет существующие методы работы, то возникают сложности. Пользователи знают, как работает этот продукт и что он позволяет делать. Но как решить свои конкретные задачи? Или другими словами: как мне в новом ПО делать свою работу?

В результате выясняется: чтобы эффективно использовать новое решение, нужно:

• перестраивать свою работу под возможности продукта или же наоборот — настраивать его под свои задачи;
• интегрировать технологию с уже существующими на предприятии решениями (рис. 1).

На этом этапе пользователи уже начинают говорить, что решение не соответствует их требованиям и потребностям.

Сложности интеграции ПО разных вендоров (производителей)

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

Попробуем применить системный поход к решению этой задачи и предположим, что базовая модель, применяемая при внедрении ИТ-решения представлена в виде треугольника «люди — процессы — технологии» (People — Process — Technology) (рис. 2).

Если перефразировать вынесенное в эпиграф высказывание Билла Гейтса, можно сказать следующее:

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

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

Треугольник взаимодействия «люди — процессы — технологии»

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

Прежде всего рассмотрим первую составляющую — «люди» («организация»). Для этого сравним существующие подходы к управлению предприятием (функциональный и процессный).

Функциональный подход

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

Пример функционального подхода: «Кто сшил костюм?» (А. Райкин)

Подчиненный отвечает только за порученные ему функции и, возможно, за деятельность своего подразделения. Функции и результаты работы параллельных структурных единиц сотрудника не интересуют. Достаточно вспомнить легендарную миниатюру в исполнении Аркадия Райкина, где он пытался выяснить, кто сшил костюм (рис. 3). И в результате выяснилось, что в ателье узкая специализация, каждый отвечает только за свою часть. И выходит, что к пуговицам претензий нет, а клиент остался недоволен.

Барьеры при взаимодействии между подразделениями

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

Процессный подход

В этом случае каждая структурная единица обеспечивает выполнение конкретных бизнес-процессов, в которых она участвует (рис. 5). Обязанности, область ответственности, критерии успешной деятельности для каждой структурной единицы сформулированы и имеют смысл лишь в контексте конкретного бизнес-процесса. Горизонтальные связи между структурными единицами при таком подходе значительно сильнее, чем в случае функционального подхода. Вертикальные связи между структурными единицами и по линии «начальник-подчиненный» несколько слабее.

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

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

Выделение процесса как объекта позволяет:

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

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

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

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

Графическое представление бизнес-процесса

В настоящее время существует много подходов или стандартов описания бизнес-процессов, среди которых:

• IDEF0;
• IDEF3;
• DFD (Data Flow Diagram);
• WFD (Work Flow Diagram);
• BAAN;
• ORACLE;
• ARIS (Architecture of Integrated Information Systems);
• BPMN
  и др.

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

Я рекомендую нотацию BPMN 2.0 (рис. 7), которая используется для описания бизнес-процесса с целью его последующего моделирования. Это значит, что если есть описанный процесс в нотации BPMN 2.0, то его без программирования можно превратить в «исполняемую» бизнес-модель.

Модель и нотация бизнес-процессов (BPMN, Business Process Modeland Notation) — методология моделирования, анализа и реорганизации бизнес-процессов. Business Process Management Initiative (BPMI) разработана в 2005 году и поддерживается и развивается Object Management Group (OMG). В отличие от других методологий бизнес-моделирования, имеющих статус «фирменного» (EPC) или «национального» (IDEF0) стандарта, BPMN получила международный статус — Международная организация по стандартизации опубликовала стандарт «ISO/IEC 19510:2013. Information technology — Object Management Group. Business Process Model and Notation».

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

Элементы (символы) графической нотации BPMN по назначению объединены в категории:

• объекты потока (Flow Objects);
• данные (Data);
• зоны ответственности (Swimlanes);
• соединяющие элементы (Connecting Objects);
• артефакты (Artifacts).

Пример бизнес-процесса в нотации BPMN 2

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

Рассмотрим ряд проблем, связанных с внедрением процессного подхода в организациях:

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

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

• процессы не формализованы должным образом;
• отсутствуют регламенты и стандарты по работе с использованием новой технологии.

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

Процессный подход к внедрению информационных технологий

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

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

Первый уровень диаграммы (бизнес-уровень)

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

На диаграмме показано (рис. 9):

• начало процесса;
• различные действия (задачи);
• проверка условий;
• окончание процесса.

Уровень 1: описание бизнес-процессов с указанием ролей

Бизнес-процесс создания нового изделия показан упрощенно. В нашем процессе есть задача № 1: создать 3D-модель. Для описания этой задачи переходим на следующий уровень.

Второй уровень диаграммы (основан на интеграции программного обеспечения)

Этот уровень связан с первым уровнем диаграммы. Нумерация показывает, что это второй уровень описания процессов. Целью данного уровня является показать, как и в каком ПО выполняется задача, а именно — создать 3D-модель. На приведенной схеме (рис. 10) показано, как взаимодействует программное обеспечение между собой: ПО № 1, ПО № 2, ПО № 3. Результатом является выполнение задачи уровня № 1, а именно — «3D-модель создана».

Уровень 2: описание процессов с указанием ПО

Для описания задачи 1.1 «Сформировать исходные данные» переходим на следующий, третий уровень.

Третий уровень диаграммы: детальное описание действий пользователя для получения результата

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

Уровень 3: детальное описание процессов

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

В результате ваш сотрудник будет знать:

• что нужно делать, чтобы получить на выходе продукт, нужный потребителю (уровень № 1 диаграммы);
• какое ПО и в какой момент нужно использовать, и как-то или иное ПО взаимодействует друг с другом (уровень № 2 диаграммы);
• как делать свою работу в новом ПО (уровень № 3 диаграммы).

Обычно результатом работы является описание бизнес-процессов и выпуск регламентов, стандартов и инструкций пользователя. Графическое описание позволяет выпускать такие документы автоматически с учетом настроенных шаблонов. Если сделать только эту часть работы, то по истечении определенного времени сотрудники забудут, что было написано в документах. Наиболее продвинутые организации уже сейчас создают на предприятии специальный web-портал (рис. 12), где хранятся и актуализируются все регламенты и стандарты. В данном случае сотрудник может «освежить» свои знания и ознакомиться с изменениями в бизнес-процессах в удобном для него виде.

Web-портал бизнес-процессов

Но и это еще не всё. Следующим вашим шагом после описания бизнес-процессов может стать применение технологии BPMS (Business Process Management Suite): класс программного обеспечения для управления бизнес-процессами и административными регламентами. Основные функции BPMS — моделирование, исполнение и мониторинг бизнес-процессов.

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

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

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

Скачать статью в формате PDF — 2.31 Мбайт