Описание бизнес-процессов – waste? Докладчик: Максим Цепков (M.Tsepkov@custis.ru) www.custis.ru Software Project Management Conference 26 ноября 2011, - презентация

1 Описание бизнес-процессов – waste? Докладчик: Максим Цепков Software Project Management Conference 26 ноября 2011, Санкт-Петербург

2 Теория: –Описание бизнес-процессов == Зрелость компании Практика: –В теории это так, но… –Впрочем, не будем останавливаться на мелочах… Диалог теории и практики 2/432/43 На самом деле, пришла пора поправить теорию!

3 Описания бизнес-процессов 3/433/43

4 TO DO или FAQ для начинающего Схемы верхнего уровня Правила – что делать в конкретном случае Устаревшие схемы и описания времен становления Краткие должностные инструкции Большие регламенты, слабо пригодные к исполнению Толстые красивые книги от консультантов Виды описаний бизнес-процессов 4/434/43

5 Договориться, как делать Разобраться, как оно работает Обеспечить единообразное исполнение Получить сертификаты (ISO, CMMI) Чтобы определить нарушителя ? Потому что так принято в компании ? Потому начальник считает, что так – правильно Зачем описывать бизнес-процессы? 5/435/43

6 Описание процессов – свидетельство их осознания Позволяет отчуждать процессы от исполнителей Без описания невозможна жесткость процессов Аморфные процессы нельзя улучшать Что говорит теория? 6/436/43 Идеал – полная и непротиворечивая система документов

7 TO DO или FAQ для начинающего Схемы верхнего уровня Правила – что делать в конкретном случае Устаревшие схемы и описания времен становления Краткие должностные инструкции Большие регламенты, слабо пригодные к исполнению Толстые красивые книги от консультантов Возвращаясь к вариантам описаний… 7/437/43 Образцы, наиболее соответствующие теории – наименее полезны

8 Полные описания – инерция прошлого Сейчас эти цели достигают по-другому… 8/438/43

9 Современные компании сильно автоматизированы Многие процессы выполняются полуавтоматически Информационная система определяет процесс гораздо надежнее регламентов и инструкций Даже когда система ведет не жестко, нарушение правил использования будет замечено коллегами Автоматизация фиксирует процессы 9/439/43 Нет смысла дублировать в описании то, что зафиксировано в системе

10 Интернет-магазин Заказы создаются покупателями или операторами на телефоне Накопленные в системе заказы – готовятся к исполнению При необходимости – операторы уточняют заказы в системе В день исполнения склад отгружает товар, курьеры – развозят Банковское обслуживание Операционисты принимают и вводят в систему документы Документы поступают к исполнителям по профилю подразделений Исполнители – проверяют и массово обрабатывают, например, отправляя платежи в РКЦ или заявки на биржу Результат исполнения поступает через операционистов клиентам Примеры из бизнеса 10/43 IT-система ведет бизнес-процесс, обеспечивает взаимодействие подразделений

11 Описание высоко автоматизированного процесса: При появлении нового документа – нажмите «Обработать» Если при обработке возникнут ошибке - разберитесь Вариант: В 11 часов нажмите большую зеленую кнопку. Дождитесь сообщения об успехе. Если будут сообщения о проблемах – разберитесь. К 12 часам надо закончить, если нет – зовите начальство. Разбор проблем регламентирован слабо Обобщаем описания процессов 11/43 Похоже на разбор багов от заказчика и процедуры выпуска версий

12 Автоматизация процесса в IT-компаниях Системы ведения дел и/или bug-трекеры Системы контроля версий, continuous integration, автотесты И другие… Участники проекта используют системы одинаково Все это хорошо фиксирует процесс Поговорим об IT-компаниях 12/43

13 Есть рамочное описание процесса Есть артефакты, его обеспечивающие Доски Backlog Общение в команде дает единое понимание Сборка и хранение кода автоматизировано В разных командах – процесс вариативен В ходе проекта – процесс меняется, адаптируется Аgile без автоматизации? 13/43 Процесс достаточно фиксирован

14 Мерить показатели – не проблема, вопрос – зачем? Примитивный подход (штрафы и премии) ведет к работе на показатели, а не на результат Мониторинг показателей – для уверенности в нормальном ходе процесса Если что-то стало не так – надо разбираться, и способ разбора не регламентируешь Пара слов о показателях 14/43

15 Идеал прошлого Тщательные спецификации программы Описание кода в отдельных документах Лозунг: лучшая документация – код программы Сначала – комментарии как средства документирования Потом – говорящие идентификаторы и ясный код XP: стандарт кодирования + метафора системы Аналогия: документация 15/43 С описаниями бизнес-процессов произойдет то же самое… Достаточно!

16 Описания бизнес-процессов в условиях автоматизации 16/43

17 Инструкции для новичков – не лучший способ, наставничество или обучение – эффективнее Но краткие справки пользователю – полезны И рамочные описания – тоже полезны Там, где IT-система ведет – документы излишни Там, где IT-система допускает альтернативы, необходимость описаний зависит от конкретики Потребность в описаниях 17/43 Необходимость описаний определяем, соотнося их пользу и стоимость

18 Подробные описания нужны только на этапе построения процесса Потом процесс живет и изменяется, улучшается Постоянная актуальность документа – требует времени и не является необходимой для процесса Но если жизнь процесса долгая – иногда наводим резкость Актуальные описания – дорого 18/43 Забота о постоянной актуальности описаний бизнес-процессов – лишний и дорогой перфекционизм

19 Схемы верхнего уровня организации процесса TO DO для начинающих – там, где полезно FAQ для начинающих и по редким ситуациям Документы, по которым о процессе договаривались Документы, описывающие изменения процессов Документы для сертификации и внешнего мира Какие описания сохраняются? 19/43 Концепция актуального и полного описания – более не актуальна

20 Объяснять так же, как остальной agile: Рамочные описания – обычно есть Гибкость и адаптивность процесса Автоматизация и прозрачность Интерактив и презентации Если надо, можно породить описания в моменте Непосредственные участники от заказчика обычно понимают преимущества Как объяснить заказчику процессы без полных описаний? 20/43 Как для сертификации Прозрачное и успешное движение проекта – лучший аргумент

21 Полное, актуальное описание автоматизированных бизнес-процессов, как правило, не нужно. Связь наличия описаний со зрелостью компании – дань прошлому. Но ею не стоит пренебрегать. Необходимость конкретных документов оцениваем в каждом случае, соотнося их пользу и стоимость. Выводы 21/43

22 Спасибо! Вопросы? Максим Цепков 22/43