Knowledge Management Software - Системы управления знаниями KMSOFT: Управление знаниями, автоматизация документооборота Программные решения KMSOFT в сфере менеджмента знаний: Е-МАСТЕР: Управление знаниями, Е-МАСТЕР: Документооборот Copyright © KMSOFT, 2002-2023 info@kmsoft-is.com Terms of use Privacy Policy
KMSOFT - Системы управления знаниями KMSOFT: Менеджмент знаний, автоматизация документооборота, системы класса ECM (управление корпоративной информацией) Информация о продуктах и услугах в сфере менеджмента знаний »»»
««« Описание программных решений в сфере менеджмента знаний: Е-МАСТЕР: Управление знаниями, Е-МАСТЕР: Документооборот
Продукты и услуги
Продукты и услуги
Статьи
Статьи
Теория
Теория
Экстранет
Экстранет
Поддержка
Поддержка
О Фирме
О Фирме
Статьи
Расширенный поиск
Найти

Основные публикации по менеджменту знаний

Избранные статьи по менеджменту знаний

Антология статей по менеджменту знаний

Глоссарий

Библиотека статей
Главная Статьи Антология статей по менеджменту знаний

Описание системы и спецификаций процессов

Этапы построения модели процессов

  1. Этап анализа и фиксации существующей организационно-функциональной структуры предприятия  
  2. Этап  «идентификация процессов» предприятия 
    1. «Перегруппировка» функций 

    2. Восстановление «неполных» процессов

    3. Согласование «функционала»

    4. Определение назначения и результатов процессов

  3. Этап выявления связей и закрепления процессов

    1. Задачи «установления» направленных связей

    2. Матрицы «закрепления»

    3. Матрицы «ответственности»

    4. Другие матрицы «закрепления» первого уровня

    5. Матрицы «закрепления» второго уровня

    6. Процессно-ролевая структура

    7. Спецификации всех процессов компании

Приложения:

 

Описание системы и спецификаций процессов

Если для потокового описания процессов существуют хорошо проработанные методологии (например, SADT или ARIS ), то процедуры выявления и систематизации процессов, представления их в виде непротиворечивой целенаправленной системы практически отсутствуют. Ни одна убедительная попытка представить полную картину деятельности предприятия в виде потоковой модели (например, в формате IDEF ) нам не известна. Предлагаемая технология, разработанная БИГ-СПб направлена на восполнение этого пробела в представлении компании, как системы процессов. С помощью матричных моделей процессы компании могут быть определены и описаны как статическая взаимосвязанная система. Спецификация каждого процесса в такой системе может быть выведена из бизнес-модели компании в отчет, например, такого формата:

  • Идентификатор и Наименование процесса
  • Назначение и цели процесса
  • Владелец процесса
  • Участники процесса
  • Предшествующий процесс (ы)
  • Следующий процесс (ы)
  • Преобразуемые ресурсы (на входе и выходе процесса)
  • Нормативные документы, регулирующие процесс
  • Документы или события инициирующие процесс
  • Документы или записи порождаемые процессом

и т.д.

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

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

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

Этапы построения процессной модели.

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

1.Процедура описания начинается с подготовительного этапа: анализа и фиксации существующей организационной структуры предприятия.

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

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

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

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

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

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

2.2. Тем не менее после такого описания большинство процессов, во всяком случае на документальном уровне, по так называемой «шкале зрелости» (см. Приложение 3) будут находиться на стадии «Неполный процесс» – уровень доказательства их систематического и контролируемого выполнения отсутствует либо недостаточен. Но теперь для получением большей точности описания уже возможен первичный управленческий анализ полученного «функционала»: 

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

В результате дополнительного анализа происходит частичное восстановление «неполных» процессов и их первичное процессное осмысление.

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

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

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

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

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

2.3.Пример согласованной модели Основной бизнес-цепочки:

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

2.4. После чего, для всех согласованных процессов (на выбранном уровне) следует попытаться определить его основное назначение и результаты (итог) процесса в следующем формате:

  • Назначение процесса «ХХХ» является ….

  • В результате реализации процесса «ХХХ» будет получено …

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

Пример фрагмента модели Основной бизнес-цепочки на уровне: «Выполняемый процесс»:

В результате этого этапа процессы компании определены и по «шкале зрелости» - перешли на уровень «Выполняемый процесс» – реализуемый процесс достигает явно идентифицированных результатов.

3. На следующем этапе события могут развиваться в двух относительно независимых направлениях:

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

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

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

3.1.1.1. Пример фрагмента модели Основной бизнес-цепочки с установлением связей и документооборота.

3.1.1.2. Пример фрагмента модели Основной бизнес-цепочки с установлением связей и ресурсооборота.

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

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

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

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

или так :

«Развернутый» процесс выглядит следующим образом:

3.2.2. Аналогично строятся и другие матрицы закрепления:

  • Закрепления операций процесса за средствами их реализации (Оборудованием, Компьютерами, Программными средствами)

  • Закрепления операций процесса за средствами регламентации их выполнения - к их числу могут относиться:

  • Внутренние регламенты предприятия (в том числе документы системы менеджмента качества (СМК)

  • Внешние документы – например, требования стандартов ИСО или действующего законодательства (нормативных актов)

  • Критерии и методы оценки качества выполнения и результатов процесса

  • Цели компании, на достижение которых влияет процесс

и т.п.

Например, закрепление средств реализации процессов :

или подробнее :

Или пример, идентификации соответствия выполняемых процессов регламентирующей документации

3.2.3.) Возможно строить и матрицы закрепления второго уровня, которые позволят вывести в спецификации процесса такие отношения:

  • Закрепление за Исполнителями - Требований к квалификации

  • Идентификация размещения оборудования (проекция Основные средства – Топология предприятия

и т.п.

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

3.3. Более современный подход к формированию требований связан с понятием «процессно-ролевой структуры»: требования к персоналу начинаются с требований к ролям в различных процессах в которых он участвует.

Процесс, как правило - и это тоже критерий его выделения, дело «командное». Команда процесса, также как и команда проекта характеризуется определенным составом ролей участников. Например, классические роли в проектах создания сложных технических систем - Главный конструктор, Руководитель заказа по экономике, Ответственный за производство и отработку, Ведущий от Заказчика по проекту,   Зам. Главного конструктора по ПМО, Ответственный за сопровождение документации и т.п. Есть свои традиционные роли и в строительных (Например, Прораб!), рекламных (Например, Криэйтор) и т.п. проектах. Процессы это постоянно реализуемые «проекты» в различных функциональных областях (процессы: основные, менеджмента, обеспечивающие)  В процессе – обязательно должна быть определена роль Владельца (Классический пример «команды» процесса – «бригада главного хирурга»). Т.е. специфика каждого процесса определяет состав других ролей и их возможных исполнителей, включая «второй состав», из числа сотрудников, представленных их должностями в организационной структуре и штатном расписании. (Так же и проектная структура не соответствует структуре организации. Иначе, происходили такие парадоксы, наблюдавшиеся в недавнем прошлом - структура создаваемого изделия часто соответствовала структуре организации (ий), которые его создавали!). Именно к каждой роли и выдвигаются определенные квалификационные требования (типа «должен знать и уметь» в классических вариантах советских квалификационных справочников). Данные справочники исходили из единой модели предприятия с небольшими отраслевыми различиями и фиксированной системой процессов, распределенных по ячейкам специализированных звеньев организационной структуры, в пределах которых они были локализованы (принцип «разделения труда»). Роли в таких специализированных процессах практически идеально соответствовали должностям. Межфункциональные процессы были крайне редки и протекали с большими трудностями (транзакционные издержки на стыке подразделений). В новой парадигме совокупность требований к должности вытекает из совокупности требований к ролям, в тех процессах, в которых она (должность) участвует или может участвовать. Возможный механизм реализации:   запись требований к роли в подуровне ролевой структуры – структуры команд «интегрированных» процессов и проектов организации. Специализированные (унифицированные) процессы – замыкаются в пределах подразделений и роли там точно соответствуют должностям.

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

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

Пример спецификации процесса «Преддоговорная работа с заказчиком»

Пример спецификации процесса «Программирование ППЗУ электронных блоков»

< Назад   Вперед >

 
Источник: kmtec.ru
Версия для печати  |  Пользовательское соглашение
Статьи
KMSOFT: Управление знаниями, автоматизация документооборота, управление корпоративной информацией
К началу страницы ...