При обсуждении систем адаптивного кейс-менеджмента регулярно возникает вопрос кто же заказчик такого решения? Какое подразделение организации должно курировать ACM. Заказчиком системы электронного документооборота (СЭД) является канцелярия, системы управления проектами – проектный офис, а кому нужен кейс-менеджмент? Одним из потребителей решений данного класса является Общий центр обслуживания (Shared services center).
Термин Общий центр обслуживания встречается у нас пока не часто (хотя гугл знает несколько отечественных кейсов). Речь идет о выделенном подразделении компании, которое обслуживает внутреннего клиента. Это похоже на ИТ подразделение, но это не только ИТ. Помимо ИТ-сервисов такой центр берет на себя функции бухгалтерии, управления персоналом, поддержки закупок и пр., т.е. функции, реализующие поддерживающие бизнес-процессы и являющиеся центрами затрат. Естественно, это делается для сокращения этих самых затрат. Для холдингов или многофилиальных компаний такая орг.стурктура может оказаться достаточно эффективной. Не держать же в каждой «дочке» или филиале отдельный штат, реализующий ИТ, закупки или выдачу справок с места работы.
Почему эту задачу лучше решать при помощи систем кейс-менеджмента, а не традиционной BPMs? Причин несколько:
- Традиционные системы управления бизнес-процессами хорошо подходят там, где мы мало что знаем о нашем клиенте и хотим обработать его запрос попроще и побыстрее. Для внутрикорпоративного центра обслуживания это не самая лучшая стратегия. Наоборот, нам удобнее консолидировать запросы одного подразделения(филиала), возможно, управлять их приоритетами или объединять схожие запросы. Например, крайне неразумно поручить подбор сотрудников на одинаковую должность в одном и том же подразделении разным рекрутерам. Или же десять раз посылать электрика в один и тот же филиал, чтоб заменить десять перегоревших лампочек.
- Процесс согласования заявок проходит как через подразделение заказчика (виза руководителя, ответственного за бюджет подразделения и пр.), так и через подразделение, исполняющее заявку. А BPM системы обладают туннельным эффектом: если заявка стартовала бизнес-процесс «А», но в ходе его исполнения выяснилось, что нужно было запустить процесс «B», то скорее всего нам придется вернуться в самое начало. Вообще говоря, бизнес-процессы с участием человека изобилуют запросами на проверку и уточнение, а методология BPM до сих пор не изжила представление о процессе, как о реализации простых операций на конвейере, движущемся в одном направлении.
- Ну и наконец, в общих центрах обслуживания крайне актуальная задача управления знаниями. Иначе такие подразделения из способа понижения затрат очень быстро превратятся в инструмент их бесконтрольного роста. История обработки предыдущих заявок, обсуждения, обратная связь от заказчика, неформализованные допущения и ограничения, опыт успешных и неудачных обращений, всё это просто необходимо знать.
Одним словом, у адаптивного кейс-менеджмента обнаружился крайне перспективный заказчик.
Похожие записи:
«….а методология BPM до сих пор не изжила представление о процессе, как о реализации простых операций на конвейере, движущемся в одном направлении» — not 100% correct — please see the follow blog post http://improving-bpm-systems.blogspot.com/2010/12/illustrations-for-bpm-acm-case.html
Thanks,
AS
Максим, интересное приложение для Case Management! А не могли бы Вы прояснить, в чем тут, по Вашему, заключается адаптивность? Кто, к чему, и как адаптируется 🙂 Я пытаюсь понять, чем не подходит традиционный CM, без модной приставки.
Олег, приветствую. Не хочу здесь пускаться в рассуждения о том, что такое адаптивность, про knowledge wokers, шаблоны процессов, базы знаний и т.п. Традиционный кейс-менеджмент не обладает достаточным уровнем абстрагирования.
Т.е. обычные решения по кейс-менеджменту это либо расследования, либо сопровождения случая, либо нечто похожее на документооборот. Общий центр обслуживания в них «не влезет». Будет решена только часть задач, например только оформление договоров или только подбор персонала. Это как баг-трекеры в ИТ. Вроде решения на ту же тему, но изобилуют всякими непонятными полями, типа номера версии, используемой операционной системы и т.п.
Я, кстати, нашел специализированные решения именно для Shared services center. Только пока не разбирался с ними детально
Мы это назвали банально — контакт центром.
Хотя еще иногда называем ХелпДеск.
Да, идеология асм — выручает.
Пока не смог найти решение одной проблемы…
Внешние клиенты у нас в другом решении, внутренние в АСМ. Но есть услуги, которые оказываются как внешним так и внутренним и как их регистрировать пока думаю.
Главное чтоб финансисты, бухгалтера, закупки и управление персоналом приняли правила игры в сервисы. А называть, конечно, можно разными словами
Юристы пока что согласились с энтузиазмом, персонал еще ждет (есть некоторые вопросы к подсистеме безопасности) остальные пока что под вопросом, т.е. они еще не знают о грядущем счастье ))
Пока что часть отдел делопроизводства (секретари), ИТ (техподдержка и разработчики (управление релизами)), юристы, сам контакт центр с опросами по качеству здесь же. Остальных делаем, начали юристов, на подходе персонал и финансы. В перспективе еще много чего.
По опыту, построение таких же систем на базе продвинутой ECM или ERP (дела на 1С) у меня занимало от года, а тут результаты на лицо за полгода и при этом удобство/сподручность — еще не встречал такого нигде.
В общем пока что проектом доволен. Там посмотрим как WordPress справится с нагрузками. Сейчас в нем прядка 3000 дел (кейсов), 12000 комментариев, 500 субъектов (сотрудники, клиенты) и около 100 объектов (ИТ-системы и прочее). Производительность уже начала падать, но по причине ошибок в интерфейсе, скоро их поправим и уровень производительности вернется до обычного блога.
А там посмотрим 🙂
Интересно! 🙂
Максим, мне не дает покоя риск связанный с производительностью.
WordPress работает только с MySQL. Пока там 10-20 тыс. записей — все хорошо.
Но это только начало. Организация большая. По прогнозу скоро в день будет добавляться около 1000 записей. Не знаю как себя поведет WP+MySQL в такой ситуации.
Интересуют 2 момента:
1. Можно ли и какими средствами улучшать производительность связки WP+MySQL?
2. Если у них предел ограничен, то какие решения еще можно использовать в качестве платформы для АСМ? Которые могли бы работать с другими БД и вообще в части веб. При этом желательно обладать гибкостью WP, особенно мне нравится механизм таксономий и хуков.
Видел записи о архитектуре Facebook, вижу что есть понимание таких особенностей. А у меня его нет. Хотелось бы ваши идеи услышать на этот счет…
Тестировать надо. У WP большое сообщество и множество конфигураций. Основная идея повышения производительности — кэшировать все, что можно кэшировать 🙂 Ну, а в принципе, конечно следующий шаг ACM это нереляционные базы данных. CMS-ок, сравнимых по функционалу с WP поверх нереляционок пока нет (на мой взгляд), но развивается все достаточно шустро.
Кстати о идеологии услуг и том как это воспринимают отделы.
У нас в этом плане все хорошо. Взял вот эту идею http://wpcases.com/opisanie-protsessov-eshhe-odna-tochka-zreniya-na-e-to-ponyatie/
Показал как модель процессов дружит с каталогом услуг. Отделы восприняли на ура.
Я сам удивился выводу, но описание бизнес процессов без описания услуг — как пиво без водки или водка без пива — в общем эффект слабый. А если их делать параллельно, из процедур ссылаться на услуги. Получается очень удобно и это сотрудники воспринимают на ура.
Согласен. Мне кажется модель зрелости бизнес-процессов нуждается в пересмотре. Вместо типовой пятиуровневой модели зрелости я предложил бы примерно следующее:
1. Мы знаем как мы всегда что-то делаем, но не знаем что именно
2. Мы знаем что мы делаем, но не знаем зачем
3. Мы знаем что и зачем мы делаем, но не знаем сколько мы этого делаем
.. и т.д.
Одним словом, процессы без сервисного ракурса лишены смысла