ACM = система адаптивного управления делами и как я это понимаю...

На помощь приходит идея ACM или Adaptive Case Managment! Встречаем реализацию идеи на базе DIRECTUM!

С1. Начнем с теории и ряда базовых тезисов, отражающих суть системы

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

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

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

4. Далее, система должна уметь собирать 3 типа информации о делах: характеристики, дополнительные поля и содержание.

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

4.2. Дополнительные поля. Для хранения дополнительной информации, которая также может быть нужна для работы или анализа.

4.3. Содержание нам нужно для исполнения. Чтобы понимать суть ситуации и чего нужно сделать.

5. Если говорить в термионологии СМК ИСО 9000 — это управление записями и оно важно с 2-х точек зрения:

5.1. Руководству для управления и контроля — знать состояние дел по процессам организации.

5.2. Сотрудникам для планирования своего времени и поддержания порядка в голове. Тут уже идея GTD. Суть которой в том, что внимание человека должно быть свободно от мыслей, которые выходят за рамки текущего момента и дела. А это можно сделать, только составляя списки дел. Все что ты должен сделать — должно хранить не в голове, а в списках. Иначе голова не выдерживает, начинаются стрессы, а за ними бабушка депресняк.

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

Все!

С2. Переходим к практике

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

С2.1. Начну пожалуй с наиболее близкого мне процесса — Управление ИТ

1. Чтобы не выдумывать велосипеды, берем библиотеку ITIL\ITSM. Да! Да! Построить ITSM на базе ACM это как пакетик семечек сощелкать. Если знаешь что такое ITSM.
2. Упустим суть организации процессов при ITSM, а рассмотрим результаты;
3. Сколько инцидентов было за прошедший месяц? Доля операций выполненных во время? Кто из специалистов более всего загружен? Какие объекты вызывают сбои? Сколько было вопросов? На какие темы? Инструкции плохо написаны или обучение провести? За какие операции отвечаю лично я? Что мне нужно сделать сегодня или сейчас же, а что может подождать? Каковы затраты на техническую поддержку? Какова динамика? Растет нагрузка или падает? — круто да? Но такую ITSM умеют строить все более или менее адекватные службы ИТ. Процесс называется «Управление обращениями или инцидентами». Это просто.
4. Давайте усложним задачу… как на счет процессов управления изменениями, проблемами, релизами, конфигурациями? Это уровень, до которого мало кто из ИТ-руководителей добрался… при помощи ACMS тоже решается легко. Сколько изменений запрошено пользователями? Какие согласованы, а какие отменены? По каким причинам отменили, кто и когда? Сколько изменений согласовано и выполнено? Сколько изменений было внесено в систему DIRECTUM версии 4.6, чтобы спланировать затраты при переходе на 4.7? Какие изменения при обновлении можно стереть, а какие стоит повторить? Сколько релизов или проектов в работе? Кто отвечает за проект А? В каком он состоянии? Сколько проектов выполнено за прошедший год? Сколько в ожидании? Какой бюджет на ИТ-проекты 2012 года? А 2013?
5. В общем имеем всю информацию о том, чем занимается служба ИТ в целом, и каждый специалист в частности. Можем говорить о планировании, сроках, приоритетах, бюджетах. А можем за 5 минут пробежаться глазками по спискам и накидать отчет о тех результатах, которые служба ИТ добилась за прошедший год;

С2.2. Ну наладили мы работу программистов. Хорошо! Погладили себя по головке. И тут на тебе! Появляется на горизонте ни кто бы то там, а сама СМК! Стандарты ИСО 9000! И руководство говорит, что не сертификат им нужен, а результат! Да и в СМК основной постулат касается словосочетания «Управление записями». Чтобы это могло быть? Как бы нам это реализовать? Ну, конечно же при помощи ACMS!

1. Добавляем в систему категории для процедур СМК. Это Несоответствия, Корректирующие действий, Причины. Это 3 сущности, управление которыми требуется, если мы говорим о живой СМК.
2. Очереди за услугами? Долго документы согласовываются? Бумаги теряются? Сроки нарушаются? Клиенты жалуются? Мебель разваливается в офисе? Это все отклонения! Так и запишем!
3. Но отклонения это лишь симптомы. Нужно найти причины! Определяем — записываем!
4. Раз в месяц совещание рабочей группы по СМК. Формируем отчеты о том, сколько отклонений за период выявлено, сколько проблем определено, кто ответственный, какие решения предлагаются, какие корректирующие действия следует сделать и кто их будет делать? Какие ресурсы для этого нужны?
5. Через полгода поднимаем вопрос, как у нас СМК поживает? Сколько корректирующих действий проведено? Их успешность?
6. За корректирующее действие отвечал Иванов? Иванов, ну-ка доложи об успехах? Сделал — молодец. Нет — почему?
7. Аудиты делали? Сколько? Кто? Когда? Где отчеты? Ах, вот они… к записи привязаны. Где же им еще быть?
8. Решения по аудитам выполнены? Кто не выполнил? Почему?
9. Внешние аудиторы приехали? Просят показать, как выполняется требование стандарта по управлению записями? Показываем им все записи по этим процедурам. Видим количество отклонений, корректирующих действий и их состояния. Сколько аудитов проведено и все документы.
10. В общем одним взглядом мы можем сказать действующая у нас СМК — или мертвая система с купленным сертификатом. Отдел качества — дает результаты или только разговоры разговаривает? Кто из руководителей больше внимания уделяет теме качества и вносит свой вклад?

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

С2.4. Ну и напоследок, то с чего все началось… Муниципальные услуги в администрации района.

1. Сколько услуг предоставила администрация? Доля услуг выполенных в сроки по регламентам? Кто из специалистов наиболее загружен? А кто прохлаждается? Может перераспределить нагрузочку?
2. Каким способом поступило обращение? На бумаге? Лично? Через сайт? Через СМЭВ? По телефону? Доля? Какой способ более популярен? Какой более экономичен? Почему люди идут и стоят в очередях, отвлекают специалистов вопросами и тратят свое время? Не потому ли что не в курсе про возможность задать вопрос через сайт? Может быть надо что то сделать и переключить поток обращений в Интернет? Сделали? Получилось? Изменилась доля вопросов через сайт?
3. Сколько раз обратился один гражданин за услугами? Почему нельзя уменьшить число обращений? Сделать все с одного раза, чтобы не гонять человека?
4. Петрова заболела и вне зоны связи? Какие у нее были обращения в работе? В каком состоянии? Что сделано? Переключить на Сидорову? Запросто!
5. Сколько заявлений одобрено, а сколько отменено? Причины отмены?

В общем и целом без ACMS получить такую информацию или очень сложно или не возможно.

Использование специального ПО для каждого процесса — это хорошо, но об этом мысль далее…

С2.5. А что такое адаптивность?

1. Все что было рассмотрено выше, относилось к понятию управления делами. Но в идеях ACM — не трудно заметить слово Adaptive. Что же это за адаптивность такая?
2. Рассмотрим на примере ситуации С2.4. Вот администрация муниципального района. Имеет порядка 50 услуг (процессов), а в каждом процессе определены события и процедуры, по которым эти события нужно отрабатывать. По 3-10 штук. Получаем около 250 процедур. На каждую есть регламент, в котором написано как именно эту процедуру нужно исполнять, чтобы все по закону и с учетом нормативов. Настроим систему, соберем мы по ним информацию, наладим управление. Красота!
3. Все бы хорошо! Но мы живем в большом государстве, в век современных технологий и ежедневных изменений. Нормы появляются каждый день, изменяются, отменяются. Вот пришел указ президента о том, что для социальной категории ВОВ введена дополнительная льгота на жилье. Соответственно теперь все обращения по жилью данной категории граждан нужно выполнять с учетом этого указа. Для нас это означает что добавилась процедура. Нам во-первых, нужно прописать регламент, во-вторых исполнитель должен понять по какому регламенту обрабатывать эти обращения, в третьих нам нужно контролировать сроки исполнения т.к. они могут отличаться от других процедур, а в четвертых завтра придет письмо сверху с поручением рассказать о количестве обращений по этому указу и результатах выполнения и нам нужно будет как то собрать эту информацию.
4. При наличии ACMS — это не проблема. Добавляем новую категорию «Предоставление жилья участникам ВОВ», привязываем сюда регламент, указываем нормы сроков и варианты результатов. Все! Теперь мы все обращения по этим условия — регистрируем по этой категории, исполнитель может открыть регламент если нужно, видит сроки и система контролирует соблюдение регламента в части сроков и результатов. Сохраняется вся информация. Все документы, которые появляются в результате исполнения этой процедуры.
5. Аналогичные ситуации можно найти в любых организациях. Юристы — могут придумать новую услугу или сказать, что вот этот тип документов будет обрабатывать по упрощенной схеме и быстро, а вот этот сложно и долго. Программисты могут ввести новую услугу типа «Сопровождение Интернет-сайта», где регистрировать все сбои или поступающие сообщения для публикации на сайт из других подразделений. В общем какой бы процесс не появился сверху или из буйной головы руководства — ACMS готова под него адаптироваться и помочь сотрудникам в исполнении, а руководителям в управлении.

Каковы важные элементы описанной системы (без которых систему не построить)?

1. Идея! Без понимания сути идеи, можно даже не пытаться регулировать процессы по ACM. Она слишком проста, чтобы быть понятой большинством людей;
2. Регламенты! Должны быть написаны с понимание того, что есть Процессы, как их правильно определять и декомпозировать. Тут поможет правило ВИСИ или если перевести на английский то MECE.
3. Программа! Она очень проста, основной сложностью при построении этой программы оказалось понять простоту идеи и за год развития, вместо наращивания функционала, пришлось заниматься его обрезанием. Хотя кое-что и приходилось дописывать, но обрезали гораздо больше

p.s. Это идеология и если в данном примере речь идет о платформе ДИРЕКТУМ, это не значит что эта идею нельзя реализовать на других платформах. Просто в данной организации эта платформа подошла лучше.

p.p.s. вот тут в комментариях человек рассказал о реализации аналогичной идеи на базе 1С 8.2 http://ecm-journal.ru/post/ACM--sistema-adaptivnogo-upravlenija-delami-i-kak-ja-ehto-ponimaju.aspx