Навигация
Моделирование бизнес процессов управления: IDEF (Integration definition for function modeling)
23549
знаков
5
таблиц
3
изображения
Моделирование бизнес процессов управления: IDEF (Integration definition for function modeling)
Новиков М. В., бизнес-аналитик, аспирант
Тему статьи и смысл ее содержания определяют имеющийся практический опыт и рассмотрение с методологической точки зрения встречающихся проблем как управления в целом, так и проектирования процессов с учетом функций управления в частности, что представляется особенно актуальным как при проектировании деятельности руководителя, так и при реорганизации бизнес-процессов, определении требований к информационной системе и поддержке проекта ее внедрения.
Прежде всего, необходимо заметить следующий факт. В настоящее время умственные ресурсы, вкладываемые в свою деятельность руководителем любого ранга, по своему эффекту во многом неудовлетворительны, что по большому счету является следствием слабой "вооруженности" руководителей. Наиболее частый выход из такого положения многие российские менеджеры видят в использовании общепринятых на Западе стандартов и концепций управления, а также реализующих эти стандарты информационные системы. С другой стороны, в области моделирования бизнес-процессов, как одного из инструментов для поддержки деятельности руководителя, наиболее популярными являются стандарты описания семейства методологий IDEF (Integration definition for function modeling). Но вместе с тем, что данной методологией уже вряд ли кого-то удивишь, в ее применении остаются актуальными две проблемы, проблемы именно для руководителей.
Первая заключается в использовании данных стандартов и получаемых моделей для управления организацией. Первоначальное использование IDEF, как и введение понятий "бизнес-процесс", "стандарт моделирования деятельности компании", "методология описания" и т.д., в российской компании чаще всего связано с внедрением на предприятии информационной системы. Можно даже сказать, что информационные технологии сейчас в принципе выступают мощным "локомотивом" изменений, который приводит в движение все остальные части компании. Почему именно информационные технологии? Во-первых, потому что с изменением бизнес-среды перед предприятием встают не только новые оперативные вопросы, но и появляются новые стратегические задачи развития, решение которых требует новую информацию, причем качественно новую, отражающую не только состояние, но и само строение бизнес-системы. Во-вторых, в информационных системах отражаются самые последние технические достижения, а также опыт и знания в предметных областях менеджмента. В третьих, информационная система объединяет все подразделения компании, позволяя автоматизировать многие функции по сбору и обработке информации. Но вместе с тем, цель автоматизации основных процессов текущей операционной деятельности, которая ставится перед внедрением ИС, и предопределяет результаты аналитиков и разработчиков, сводящиеся к описанию бизнес-процессов на уровне конечных исполнителей, практически без учета деятельности руководителей. Обычно последующее за этим шагом решение непосредственно включить некоторые функции управления в информационную систему и необходимость в каждом процессе видеть место руководителя приходит позднее, когда создание моделей без учета деятельности руководителей входит в привычку. Таким образом, можно сделать первое умозаключение, что само по себе моделирование бизнес-процессов или наличие информационной системы ничего не значат с точки зрения поддержки процесса управления, пока руководителем явно не будет поставлена цель "включить меня в процесс". Вторая проблема является следствием первой и связана с представлением разработанных моделей менеджерам компании. Дело в том, что полученные схемы и описания наиболее удобны разработчикам информационных систем и аналитикам, но не всегда выразительны и наглядны. Особенно если необходимо сделать презентацию сложного процесса с целью обсуждения возможных его улучшений и сравнить два варианта ("as-is" и "to-be"). То есть проблема состоит не в какой-либо методологической сложности IDEF и не в том, что менеджеры не способны ее изучить (или не хотят этого делать), а именно в выразительности схем при обсуждении и принятии решений большим количеством участников в сжатые сроки (в объеме презентации).
Таким образом, задача статьи состоит в акцентировании внимания на этих двух проблемах и в попытке понять, дополнить, обогатить "картину мира" проектирования процессов управления через преодоление данных проблем.
Как уже отмечалось, начиная описывать деятельность той или иной организации необходимо помнить, что крайне важным моментом является сама постановка и формализация цели описания. Таким образом, руководитель, взяв в руки готовые схемы бизнес-процессов, построенных, например, в стандарте IDEF0, для регламентации деятельности исполнителей или для разработки на данном уровне (настройки) ИС вполне может обнаружить следующее:
результат описания представляет собой набор схем текущей операционной деятельности, структурированных в лучшем случае по выполняющим процессы подразделениям или модулям ИС,
отсутствие среди участников процесса себя, руководителей отделов, аналитиков, плановиков и т.п.,
единственным набором изложенных правил (наполнение управляющих стрелок), в соответствии с которыми должно функционировать предприятие, является набор отдельных положений и должностных инструкций.
В результате крайне трудно использовать данные схемы, например, при:
построении процессов стратегического планирования и бюджетирования;
разработке нормативов и систем оценок качества выполнения ключевых процессов, определяющих, например, конкурентоспособность предложения компании;
построении контроля процесса и отчетности для руководителей;
определении целесообразности существования самого процесса, направления развития бизнеса, реструктуризации и т.д.
Кроме того, становится невозможной реализация в деятельности руководителя (а значит и деятельности предприятия) свойства целостности, хотя при построении схем бизнес-процессов компании это является необходимым условием. Из имеющегося опыта можно сделать заключение, что данное свойство наиболее сложно реализуемо, так как можно представить следующую формализацию [1, 4]:
C = Целостность (П, И, Н, Д),
где: С - смысл деятельности,
П - предмет деятельности,
И - инструментальная оснащенность, при ее отсутствии не может быть формализована сущность деятельности,
Н - непротиворечивость деятельности,
Д - полнота и дискретность, предельная ясность деятельности в каждой конкретной ситуации.
На рис. 1. в качестве справки приводится принцип моделирования процессов в стандарте IDEF0, подробное описание которого не входит в цели статьи (полный вариант описания можно найти в соответствующей литературе).
Очевидно, чтобы получить схему, отвечающую обозначенным выше требованиям, необходимо сменить точку зрения (определяющую основное направление развития модели) при описании бизнес-процессов. И вот здесь возникает проблема в применении существующих и, главное, освоенных стандартов к описанию бизнес-процессов с целью управления организацией, с целью связать схемы текущей операционной деятельности с деятельностью руководителей, аналитиков и т.д. Это отсутствие при описании понимания компании как системы, сути процессного подхода (как следствие некорректная постановка задачи описания) и неэффективное использование самих моделей. В лучшем случае моделирование деятельности руководителя ограничивается одной функцией с множеством входов и выходов, что не помогает в преодолении трудности достижения целостности. К сказанному можно добавить слова американского исследователя М. Месаровича [2]:
"В настоящее время уже довольно ясно, что систему нужно проектировать как целое, а не начинать с процесса и затем лишь добавлять необходимое управление. Несмотря на то, что можно привести примеры, в которых при проектировании технологии процесса учитывается и наличие управляющих подсистем, общесистемный подход, не делающий никакого разделения, все еще не реализован".
Хотя об этом много говориться, но сегодня вряд ли многие понимают актуальность и необходимость поддержания целостности выстраиваемого объекта, деятельности. Второй момент, препятствующий достижению высокой результативности работы аналитика бизнес-процессов управления, состоит в многоцелевой, разнохарактерной по направлению и предметам деятельности руководителя, в результате чего складывается впечатление отсутствия "профессиональной" целостности (впрочем, отсутствие так таковой целостности - далеко не исключение), причем как в понимании аналитика, так и самого руководителя [3].
Для того чтобы решить данную проблему предлагается графическое представление (рис. 2), которое отражает поведение компании как системы и является своеобразным шаблоном при моделировании деятельности организации, позволяя разложить стратегические цели компании на отдельные составляющие и довести их до функций конечных исполнителей.
Вся деятельность разбивается на три уровня: цели, окружающая среда, внутренняя организация, а далее организуются обратные связи между этими уровнями. Важно заметить следующее. Во-первых, такое разбиение не подразумевает соответствия выделенных уровней и организационных единиц (сотрудников), их иерархий. Второй важный момент заключается в том, что под "организацией" подразумевается не только компания целиком, а может рассматриваться служба, отдел и т.д. То есть упомянутые три уровня (цель, окружающая среда, внутренняя организация) присутствуют как на уровне всей системы, так и на уровне каждой подсистемы. Другое дело, что целями подсистем являются результаты процессов "верхнего" уровня, а окружающая среда может включать и другие подсистемы.
Чтобы лучше понять суть подхода, приводится сквозной пример моделирования гипотетического процесса "Продажа", который наверняка присущ в том или ином виде практически для любой организации, если его понимать как формирование потока обязательств между организацией и окружающей средой. Необходимо отметить, что описание проводится с ориентацией на руководителя, с целью выделить предмет и содержание его работы и их место в общей деятельности компании (которые и должен зафиксировать аналитик). Таким образом, то, что описание третьего уровня, на котором осуществляется основная "по объему" деятельность предприятия, будет рассматриваться только в общих чертах - не является случайностью или упущением.
Рис. 2. Модель бизнес-процессов.
Похожие работы
... ; - контроль соответствия фактических и плановых данных об объеме производства; - анализ отклонений фактических данных от установленных плановых показателей. 3. Автоматизированная система учета производственного процесса металлоцентра 3.1 Программно-технические средства общего назначения Основным программным обеспечением всех, без исключений, компьютеров ИС является операционная ...
... проекта. В этом случае редактор кода вызывается кнопкой View Code (Просмотр кода) панели инструментов окна Проводника. 2.3 Характеристика программы Данная программа написана на языке Visual Basic 6.0 и представляет собой 1 приложением, предназначенных выполнять все функции, которые требуются заданию. В конечный продукт входит 1 откомпилированное приложения, размер которого составляет ...
... продукта - кафедра ИИТ, в лице преподавателя Грибанова А.О 2.1.4 Документ, на основании которого ведется разработка Разработка ведётся на основании задания по дисциплине «Проектирование информационных систем». 2.1.5 Порядок оформления и предъявления заказчику результатов работ по созданию системы Система передается в виде курсового проекта в сроки, установленные заданием по дисциплине « ...
... оформления : ДСТУ 3008–95. – Киев: Госстандарт Украины, 1995. – 38 с. – (Государственный стандарт Украины). Додаток До пояснювальної записки дипломного проекту "Розробка автоматизованого робочого місця управління замовленнями у малому бізнесі (ПП "Сігма")" Вихідний код програми Public Class frmГлавная Inherits System.Windows.Forms.Form Private Готов As Boolean = False Private ...
0 комментариев