Описание процессов в ... PowerPoint?

pptЯ уже как-то писал, что и в нашей проектной практике, и во внутренней корпоративной жизни мы принципиально стараемся делать описания процессов как можно короче. При этом, как правило, помимо регламента процесса в виде текстового документа, приходится делать какую-то презентацию для представления процесса руководству и обучения исполнителей. В течение последних двух лет мы несколько раз применяли следующую практику: описывать процесс только в виде презентации, вообще без традиционного «вордовского» регламента. Каковы плюсы и минусы такого подхода?

Основной и очевидный плюс – короче и доступнее изложение. При том, что презентация по процессу содержит все основные разделы регламента – назначение, принципы организации, связи с другими процессами, роли, процедуры, RACI, измерение и оценка, – она содержит всего 15-25 слайдов, просмотреть которые по силам всем (это точно проще 30-40 страниц плотного «регламентного» текста).

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

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

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

P.S. Стратеги, размышляющие о будущем с использованием таких терминов, как, например, «поколение Z», привыкшее к Facebook и Instagram, вообще утверждают, что картинки – это единственный способ донести информацию до индивидуума. Так что история повторяется, теперь уже на нас: «Вот в наше время хорошие документы уважали, читали, цитировали, применяли. Не то, что нынешняя молодежь!» 🙂

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

Узнайте больше!

Комментарии и мнения

  1. Nargiza Suleymanova

    Для меня вообще самые важные составляющие описания любого процесса - это графическая схема + сопутствующие таблицы. Сама пользуюсь простейшими фигурами BPMN, необходимый минимум — это функции (чтобы понимать, кто участвует), события (начальные, промежуточные и завершающие), задачи и шлюзы. Так проще и писать алгоритм, и объяснять его потом заинтересованным лицам.

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

    Мысль несомненно интересная 🙂

      1. Александр

        Дмитрий, ваш ответ очень похож на ответ почтальона Печкина: "Посылку я вам принес, но я вам ее не отдам". Что мешает убрать из презентации информацию о Заказчике, или назвать его ООО "Ромашка". Оценить вашу идею можно лишь увидев качество презентации, а если еще добавить информацию "сколько времени ее делали", то цены вам не будет©

        1. Дмитрий Исайченко Автор

          Что мешает убрать из презентации информацию о Заказчике, или назвать его ООО "Ромашка"

          Контрактные обязательства. Кроме того, я полагаю, что идея и шаблон документа — не одно и то же. Поэтому сравнение с тов. Печкиным мне не кажется обоснованным. Но убеждать не буду — у каждого свое мнение.

  2. Евгений Шилов

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

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

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

  3. Сергей Терехин

    У меня идентичная практика:

    1) Всё начинается с презентаций регламентов в Power Point (используется на обучении + комментарии + демо). Раньше делал ссылки на разделы в регламентах, но потом перестал, т.к. сама презентация отражает структуру регламента (условно говоря: названия разделов и их последовательность. Ну и сам регламент хорошо структурирован, чтобы в нём было просто всё искать).

    2) Далее идут Quick Guides, чтобы быстро и без вопросов воспользоваться системой

    3) Ролевые инструкции — где в общих чертах со ссылками на регламенты определяется что и как для конкретной роли

    4) Регламенты

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

  4. Андрей

    Вспомнился случай 10-летней давности. На одном металлургическом предприятии  крупные интеграторы/консультанты внедряли ERP. ИТ директор предприятия в начале проекта попросил внедренцев представить модель бизнесс процессов, которые будут внедряться. Внедренцы обиженным тоном спросили

    -А до какого уровня детализации вы хотите?

    — До уровня, когда я смогу отличить процессы птицефабрики от процессов металлургического комбината.

    В результате они принесли ему картинки в PowerPoint (правда к чести этих персонажей надо отметить, что они хотя бы нотацию нормальную использовали, видимо еще оставались какие-то знания). Из это стало очевидно, что использовать нормальные технологии процессного моделирования/внедрения  консультатнты не собирались, поскольку рисунки в PowerPoint не обеспечивают полноценного анализа и дальнейших проектных шагов. Кстати, ИТ директора выгнали — слишком умный был, а цель проекта, как оаказалось, была за три года внедрить, чтобы на внешний IPO выйти, а не полноценая информационная система. Типа как в Связьинвесте — "цель проекта — повысить капитализацию компании", читай — фиктивно накрутить основные средства.

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

    Хотя, что говорить. ITIL  до сих пор не содержит нормального описания бизнесс процессов. Попытки предпринимаются, Brian Johnson поделился пару лет назад некими наработками, но сделано это так, что практически мало применимо — кавдратики с иманами проессов и стрелочки/связи с именами объектов. Что за связи — вход/контроль/инструмент? — фиг поймешь. Но все таки лучше чем ничего.

  5. Владимир

    Везде нужно искать золотую середину. Главное в документе — соразмерная полнота и понятность.

    Если тема большая — её целесообразно дробить.

    Не в каждом процессе можно допустить вольности исполнения. Представьте, что Вы вместо заявления на отпуск — рисуете картинку с уставшим плачущим человечком 🙂

    Если Вы, как Исполнитель вредрения Service Desk, вместо документации принесете Презентацию — я Вас не пойму. Если принесете Презентацию процесса вместе с документацией — это будет The Best.

    Вспоминаю случай, когда в одном филиале на процесс заправки картриджей уходило 14 (!) человеко часов: когда привозили заправленные картриджи — сотрудник с ними уходил на склад; подключал нужный принтер; вставлял нужный картридж; печатал несколько страниц. Если картридж мазал – отдавал на обмен заправщику. Спрашивается, какого рожна так выстроен процесс: неужели нельзя печатать несколько тестовых страниц на боевом принтере в момент замены закончившегося картриджа?! А теперь спрашивается, неужели про ЭТО нужно писать в Регламенте?

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20