Как описать бизнес-процесс компании, чтобы новичок быстро все понял и не зарылся в бюрократии
Всем привет! Меня зовут Алексей, я занимаюсь внедрением инструментов управленческого контроля в бизнес (преимущественно на базе Platrum), таких как: организующая схема, метрики сотрудников, база знаний, обучение сотрудников и т.д. Другими словами, занимаюсь систематизацией бизнеса.
В этом кейсе расскажу, какие работы я провел в рамках проекта, чтобы новичку в компании было проще разобраться, чем он будет заниматься, с кем из других отделов и на каком этапе будет взаимодействовать, каких результатов от него ждет руководитель.
О проекте
Компания Waymorr занимается продажей майнингового оборудования, предоставлением аренды размещения в майнинг-отеле, а также разработкой специализированного ПО для оценки работоспособности оборудования для майнинга.
Запрос
Собственник компании обратился ко мне за консультацией по работе с сервисом автоматизации менеджмента Platrum. Запрос был такой:
- Сделать так, чтобы каждый новый сотрудник мог легко разобраться, с кем из других отделов и на каком этапе он взаимодействует в рамках своей деятельности;
- Помочь с построением структуры компании - какой она должна быть с точки зрения отделов, каковы функциональные обязанности сотрудников и результаты деятельности каждого из них.
Исходные данные
Клиент сам зарегистрировался в Platrum и взял один из предложенных шаблонов орг.схемы, расставил на ней сотрудников. Но так как это был всего лишь шаблон - естественно, он не отражал реальной картины, и потому нужно было помочь выстроить все в актуальном виде.
Реализация
Подготовка
Если со структурой компании в плане реализации для меня уже все было просто и понятно, то как описать взаимодействие отделов и сотрудников, нужно было еще разобраться. Я помнил, что когда-то давно создавал себе шаблон регламента взаимодействия между отделами, который в теории должен был решить эту задачу.
Шаблон содержал перечисление всех функциональных отделов и должностей в них, функции каждой должности и результаты деятельности (ЦКП - ценный конечный продукт). За каждой должностью была прикреплена табличка, содержащая 5 столбцов:
- Что мы принимаем от предыдущей должности (вход),
- Критерии приемки,
- Что делаем на этом шаге (процесс),
- Кому передаем информацию дальше (выход),
- Критерии передачи.
В целом документ был как будто бы неплох, и из него легко бралась необходимая информация для орг.схемы (отделы, основные функции, ЦКП). Также из него потом можно было взять много полезного при построения базы знаний. И вроде бы он как раз показывал, кто с кем взаимодействует. Решил начать работать в нем.
Старт работы
С собственником и сотрудниками разобрали отдел продаж, заодно захватив некоторые функции других отделов, которые с ним взаимодействовали (юр. отдел, закупки, бухгалтерия, фин.отдел). Результаты заносились в регламент.
В какой-то момент полотно текста стало разрастаться до таких размеров, что я сам начал в нем путаться - даже несмотря на кликабельное удобное содержание, которое предлагал текстовый редактор в базе знаний Platrum (работали сразу в нем). Собственник тем более не понимал, что происходит в файле и как с ним работать.
Встал вопрос, как нерабочий документ сделать рабочим? Как минимум, огромное полотно нужно было разбить на удобные документы, в которых бы содержалась информация только для одной должности. Точно нужно было упрощать таблицу, потому что и она получалась громоздкой и нечитабельной даже в рамках одной должности. Пришел к тому, что нужно создать документ с описанием бизнес-процесса как рабочего документа.
Что должно быть в описании бизнес-процесса?
На тот момент это был новый опыт для меня. Я начал изучать информацию по теме. В процессе понял, что нет какого-то единого шаблона для описания бизнес-процессов - каждый делает как хочет, в целом придерживаясь каких-то общих моментов. При этом объем такого документа у некоторых мог достигать более 50 страниц текста.
Такие объемы пугали и отдавали легким привкусом нечитабельной бюрократии. В большинстве случаев все выглядело громоздко, скучно, непонятно. А нам важно помнить, что документ должен быть рабочим и простым в потреблении и усвоении информации - особенно для человека, который только пришел в компанию.
После нескольких дней аналитики и сравнений я пришел к следующему наполнению описанного БП:
- Общая информация о документе: кто ответственный за конкретный процесс, кто еще в нем участвует, кто ответственен за актуальность и редактирование документа, кто ещё имеет право редактирования, дата и версия документа. Эту информацию можно спрятать в спойлер - текстовый редактор Platrum’а недавно стал это позволять.
- Диаграмма бизнес-процесса: наглядное представление БП в виде схемы. Лично для меня, пожалуй, это самое главное для быстрого понимания, кто что делает и на каком этапе.
- Таблица функций, входов и выходов: табличное представление бизнес-процесса с названием шага, ответственным за него, упоминанием, от кого что мы получаем и что именно и кому мы передаем.
- Описание процесса: понятное, написанное человеческом языком.
В целом пункты 2-4 представляют собой одно и тоже, но в разном исполнении. Смотря кому как удобнее воспринимать информацию. От какого-то из этих пунктов вполне можно отказаться.
Лично мне, уже на опыте использования программы и создания своих регламентов для внутреннего обучения, табличное представление кажется не самым удобным для восприятия. Есть вероятность, что я от него откажусь, оставив диаграмму и описание процесса простым языком.
Различные детали, такие как критерии приемки/передачи, время выполнения, задействованное ПО или документация - я не стал включать в описание процесса в п.3-4, посчитав это лишней информацией, которую можно спокойно вынести уже непосредственно в регламент выполнения того или иного шага БП. (Снова держим в голове цель этой работы).
О диаграммах
Остановлюсь подробнее на диаграммах. В процессе исследований мне показалось, что диаграмма процесса будет восприниматься новым сотрудником легче, чем текст (особенно в ее табличном варианте), и как минимум должна дополнять таблицу, если не заменять ее полностью.
Попробовал накидать диаграмму (пока еще без особых навыков построения) уже разобранного ранее процесса. Показал ее собственнику. Обсудив примерные времязатраты на построение, пришли к выводу, что с диаграммами будет лучше - их тоже нужно будет построить ко всем основным процессам, где задействовано много должностей.
Погрузился в тему построения диаграмм - какие бывают, чем отличаются и т.д. Я уже давно знал, что основной стандарт - это bpmn 2.0, но детально в нем разобраться пока не было времени и повода. Начав погружение в него, понял, что вот так сходу за 5 минут это невозможно - есть риск наделать много ошибок, а этого мне не хотелось.
Ну и показалось малость сложноватым оно для восприятия с точки зрения новичка (по моему субъективному мнению).
Решил придерживаться в отрисовке нотации EPC (с учетом задействованных должностей). Показалась мне она сильно проще и с точки зрения ее понимания и с точки зрения самостоятельного быстрого изучения и построения. Детальное изучение bpmn 2.0 снова отложил на будущее. Ниже скрин одного из процессов.
Допускаю что где-то могут быть ошибки в отрисовке, и что где-то что-то я не учел или сделал “не по стандартам”. Но обратная связь клиента (и будущих клиентов) на подобные диаграммы была положительной, всем все было понятно - а это самое главное. Ну и то, что я потратил на изучение минимальное количество времени, достаточное для выполнения задачи, тоже немаловажно.
О возможностях текстового редактора Platrum
Пару слов о текстовом редакторе в Platrum. Помимо базовых возможностей работы с текстом в саму статью в базе знаний можно вставить картинку, таблицу, прикрепить файл, зашить ссылку в текст, вставить аудио, видео (и смотреть его прямо из статьи), видео из внешнего источника (например, из ютуба, и так же смотреть его прямо из статьи), виджет через iframe и еще ряд ситуативных функций, на которых не буду сегодня заострять внимание.
Возможностям и работе самой базы знаний в связке с академией в Platrum я уделил большое внимание в прошлом кейсе
В рамках нашей работы еще оказалась очень полезной возможность упоминания статьи из базы знаний, конкретного пользователя или должности. Разница между двумя последними в том, что если мы указываем конкретного пользователя, то он в тексте так и останется - независимо от того, работает он с вами или ещё/уже нет. Если же упоминаем должность, то система подхватывает имя на структуре и подставляет его с упоминанием самой должности. Если вы замените человека на структуре компании, система автоматически подставит в статью имя сотрудника, который занимает должность в текущее время.
Забегая вперед скажу - возможность проваливаться в кликабельную статью на том или ином шаге описания процесса позволила создать подготовительную базу документов с точки зрения необходимых регламентов для какой-либо должности. Описывая процесс по пунктам, мы понимали, кто за него ответственен на каждом шаге - а значит, понимали, в какую именно папку (должности) нужно поместить кликабельную заготовку регламента данного шага, который останется лишь наполнить контентом, когда дело дойдет до описания самих регламентов.
Работа над структурой
Перейдем непосредственно к работе с отделами и структурой. Напомню: исходные данные - это один из предлагаемых шаблонов структуры Platrum и расставленные на нем люди без каких-либо изменений по отделам.
Разобранные БП отдела продаж позволили разграничить функционал менеджера. Если на бумаге (и практике тоже) ранее он делал вообще все, то теперь мы определили все шаги БП в отделе продаж, что позволило разделить зоны ответственности на отделы call-центра, входящих заявок и сопровождения клиентов и увидеть, где и чем заканчивается деятельность одного менеджера и начинается деятельность другого.
Соответственно, выделение функциональных обязанностей и результатов деятельности менеджеров продаж (с отображением их на структуре компании) позволяет нам лучше понять, кого нам нанимать на конкретные должности с конкретными функциями. Это может помочь сэкономить, например, на менеджере call-центра, где не требуется таких компетенций по знанию продукта - в отличие от менеджеров теплых заявок и сопровождения.
Продолжили в таком же формате (описанный БП+перенос ключевой информации на структуру) разбирать производство. С отделом закупок и логистики особо сложностей не возникло, их делали уже по разработанным согласованным материалам. Немного застопорились на складе. Там разграничили функции руководителя склада, менеджера склада и тестировщика. С сервисным центром тоже проблем не было.
Далее занялись отделом маркетинга. Разобрали его по уже действующим направлениям и обозначили те, что сейчас на паузе. Потом перешли к поддерживающим процессам - финансовому отделу, бухгалтерии, персоналу. В поддерживающих процессах особо долго разбираться не пришлось - там пока что все функции выполняет владелец. То есть, основная работа пришлась на маркетинг, продажи и производство. В конце разобрали еще IT-отдел, который создавал собственное ПО.
Итоги
В результате исследований и двойной работы (по переносу информации из старого шаблона в разработанный документ описания БП) у нас неплохо так подзатянулись сроки. В рамках компенсации я решил дать заказчику несколько больше оговоренного и сделал полностью заготовку для базы знаний всей компании. То есть, заготовил все необходимое для папки каждой должности. Что в нее должно входить, я разбирался параллельно в рамках другого проекта - это уже тема для отдельного кейса.
В рамках тех же исследований я сделал шаблон должностной инструкции и оставил его в проекте у клиента. Также выставил все доступы в получившейся базе знаний, чтобы каждый видел только то, что должен видеть (всего одна строка в тексте, за которой скрывается несколько часов монотонной технической работы).
Итак, что получилось в итоге:
- разработана структура компании в актуальном на сегодняшний день виде, с учетом развития компании в ближайшем будущем
- прописаны на орг. структуре функции сотрудников и их результаты деятельности (ЦКП)
- разработаны шаблоны документов описания бизнес-процесса, регламента, должностной инструкции
- описаны все основные бизнес-процессы компании, в которых участвовало бы двое и больше сотрудников из разных отделов
- отрисованы диаграммы бизнес-процессов для более быстрого понимания сотрудниками своих задач и их нахождения в рамках задействованного процесса в целом
- разработана база знаний, логически разделенная по разделам, по папкам каждого отдела и папкам должности
- разработана и сделана заготовка папки должности каждого сотрудника компании
- созданы и размещены в папках необходимых должностей заготовки для регламентов, необходимых для наполнения, исходя из шагов в описанных бизнес-процессах
- технически реализована взаимосвязь между документами и автоматическое упоминание сотрудника на ответственной должности
- выставлены все необходимые доступы как в разделах в базе знаний и в должностных папках, так и в документах описанных бизнес-процессов, исходя из участников процесса
Спасибо за уделенное время! Рад, если кейс оказался для вас полезным :)