На работе я занимаюсь поддержкой пользователей и обслуживанием коробочной версии CRM Битрикс24, в том числе и написанием бизнес-процессов. Нужно отметить, что на самом деле я не «чисто» специалист по Битриксу, а это одна из моих обязанностей. На самом деле обязанностей у меня очень много, поэтому почти всегда делать приходится не как хотелось бы, а быстро и чтобы работало, поскольку времени катастрофически не хватает (я уверен, что в таких условиях работаю не я один). На текущий момент у меня двухлетний опыт работы с этой CRM (с самим Битриксом знаком более 10 лет) и я хотел бы рассказать вам о части ошибок, которые я допустил при написании, тестировании и обслуживании бизнес-процессов, из-за которых мне приходилось и приходится постоянно помогать пользователям, вносить правки, а то и вовсе переписывать бизнес-процессы с нуля.
Для начала нам нужно поверить в то, что любая стабильность относительна, а нахождение в зоне комфорта временное. Сотрудники будут приходить и уходить (даже те, кто сидит на очень хорошем месте), отделы переформировываться, штат увеличиваться и уменьшаться, открываться и закрываться подразделения и т.п. Когда я учился в институте, то преподаватель по сопромату рассказывал нам о том, что при изучении сопромата в России за базу берётся статическое состояние, а потом мы учим динамику, а вот в некоторых других странах за базу берётся динамика, а статика рассматривается как частный случай динамики. Лично мне такой подход нравится больше, он не даёт возможности тешить себя тем, что «сейчас всё устаканилось и ничего меняться не будет». Просто поверьте в это, вам же будет легче потом.
Лирическое отступление: прежде чем рассказывать о том, как писать бизнес-процессы «с задатком на будущее» вы должны для себя прикинуть иерархию вашей фирмы чтобы понять, кто вообще может просить или требовать у вас написать или изменить бизнес-процесс. Один раз ко мне подошёл руководитель одного подразделения и говорит: нам нужен бизнес-процесс для взаимодействия с другими подразделениями, а то у нас всё плохо. А у них реально всё плохо тогда было, даже скорее ужасно. Я три или четыре рабочих дня писал этот БП, сделал почти идеально, а другие подразделения взяли и заявили, что бизнес-процесс этот чушь, не удобный и работать с ним они не будут от слова совсем. Я сижу, не парюсь (это же не моя проблема, там на уровне генерального директора должны были уладить), а потом приходит тот руководитель ко мне и говорит: за работу спасибо, процесс можешь удалять, генеральный позицию тех подразделений принял. И так было много раз по самым разным вопросам и изменениям. С тех пор бизнес-процессы я пишу только тогда, когда директор с этим согласен.
Теперь вернёмся к нашим бизнес-процессам. Иногда они бывают совсем маленькие, буквально на 1-2 клика, чтобы просто зафиксировать то, что кто-то попросил разрешение сделать что-то, а кто-то разрешил, чтобы не бегать с бумажками (и не потерять их). Вроде бы очевидно: подчинённый спрашивает у руководителя можно или нельзя, а руководитель нажимает на соответствующие кнопки. Просто? Да ничего подобного! А если руководителя нет? А если сейчас нужно другого было выбирать? А если был и уехал не подтвердив? А если заполнил не так? А если ещё что-то? А если… И это всё вопросы, с которыми мы постоянно боремся и делаем процесс лучше, но только до тех пор, пока не приходит новый сотрудник. Как приходит то всё начинается заново: те же вопросы, те же ошибки и т.п. Мой руководитель постоянно ругает меня за то, что я делаю мало комментариев и инструкций, но уж очень нравится мне наступать на грабли, а иногда и попрыгать по ним можно. Шучу :-) Теперь я буду поступать иначе: сначала не блок схему (как предлагает руководство пользователя), а обычную инструкцию. Если её все поняли и с ней все согласны, то потом уже рисуем блок-схему и если и с ней согласны, то пишем бизнес-процесс. Это сейчас он может быть маленьким, а со временем может разрастись до такой степени, что вы реально будете обсуждать покупку 4К телевизора с диагональю «побольше» чтобы просто увидеть сам процесс целиком и посмотреть нет ли ошибок хотя бы в логике. Кстати прежде чем приступать к написанию неплохо будет заручиться подписями всех руководителей, чьи подразделения будут пользоваться этим процессом, чтобы потом не было жалоб на неудобную работу, неправильную логику и т.п.
Именно эту фразу я теперь буду ставить во главу угла при написании бизнес-процессов. Действительно практика показывает, что должность есть, просто на ней меняются люди. Как была должность финансового директора, так и есть. Как был главный бухгалтер, так и остался. И руководитель управленческого учёта никуда не делся. А про руководителей отделов продаж я вообще молчу. Другое дело, что должности никуда не делись. Обычно же как: сидишь, работаешь, а тут тебе новость «Маша уходит, Таня приходит». Нужно сразу же судорожно вспоминать в каких бизнес-процессах человек участвует, где нужно одного на другого заменить и т.п. А могут ведь иначе сказать, просто из серии «Маша уходит». Ты человека удалил отовсюду, сидишь себе дома на больничном/в отпуске или едешь куда-нибудь, а тут звонок «у нас тут Таня вышла, только доступа нет почему-то никуда». Ну правильно, её и в Битрикс то не добавили ещё, не то что роли в бизнес-процессах прописали.
Так действительно проще, если думать не о конкретных людях, а о должностях, которые они сейчас занимают. Да, в бизнес-процессе будет 1-2 лишних блока, но зато когда человек поменяется не нужно будет вспоминать где и за что он отвечал, нужно будет просто заменить значение переменной с одного человека на другого и всё.
Гипотетически структура компании полностью вертикальна: Собственник – Директор – Главный бухгалтер – Руководитель отдела – Сотрудник (или как-то так). А может быть горизонтальная: Собственник – Директор – множество отделов. А может быть ещё какая-нибудь.
Раньше я устанавливал права для каждых конкретных сотрудников. Например: есть бухгалтер Лена, она должна видеть все оплаты и отгрузки. Заходим в соответствующие бизнес-процессы и прописываем там нашу Лену. А вдруг её переведут или она уволится? Тогда самый простой способ это давать нужные доступы всем тем, кто находится в группе «Руководители», но это неправильно, поскольку тогда процессы и файлы сотрудников будут доступны не только их руководителям и бухгалтерии, но и руководителям других отделов.
Вариантов тут множество, лично я в последнее время остановился на работе с группами. Создаём группу, добавляем в неё сотрудников (или одного сотрудника) и готово. Больше не нужно переживать по поводу того, что старый сотрудник видит много, а новый мало: просто добавляем в группу или исключаем её. Быстро и просто.
Если вы идёте к человеку с бумажной служебной запиской, то он не может устно одобрить её, он ставит подпись. Но может устно дать развёрнутый комментарий, в том числе поставить условие вида «я подпишу, но если будет получаться «вот так» то не делай/не покупай». А если подписать нужно у двоих, то, в принципе, можно пересказывать. Именно поэтому нужно сохранять вообще всё и, самое главное, никогда не прописывать «жестко» кто поставил комментарий, а всегда брать из переменной. В первое время я этим очень грешил: где должен директор подтверждать комментарии от его имени, где главбух то от его имени. А потом у людей спрашивают, почему запретили или подходят что переделали, а они и сами не в курсе, что что-то кому-то запрещали :-)
Раньше мы записывали только «финальные» файлы, но потом стали не часто, но все же, сталкиваться с тем, что люди начинают спорить на тему «я это не загружал», «когда я подтверждал файл другой был» и т.п. Или вообще стали возвращаться к бизнес-процессу через 2-3 месяца после закрытия.
Буду честным и скажу, что когда ты просишь сотрудников протестировать бизнес-процессы то им плевать. Кому-то лень (хотя сидит ничего не делает), у кого-то нет времени, а кто-то откровенно туповат и не понимает, что нужно делать. Стал тестировать один – неудобно. Стал тестировать со своим руководителем – проще и удобнее, но что ему очевидно другим нет (как я уже писал раньше инструкций-то нет, хотя вроде и очевидно). В результате решили так: я сам прохожу по каждой ветке бизнес-процесса по одному разу, потом тестирую с руководителями всё ли понятно им. Если всё понятно и я объяснил так, что они могут пересказать это своим сотрудникам, то берём по сотруднику от каждого отдела и запускаемся в принудительном порядке (хотя обычно с каждого отдела вполне можно найти добровольца). Если и тут всё нормально, то бизнес-процесс уходит в работу и тут же анонсируем его для всех сотрудников.
Иногда для ускорения работы над бизнес-процессом беру шаблон старого и правлю его. Так быстрее, но в итоге я получаю:
и ещё много чего такого, чего получить в итоге не хотелось бы. Пробовал писать с нуля – долго и неудобно. Как меньшее из зол выбрал копирование процесса и плавный обход и прочтение каждого блока, чтобы понять правильно ли я делаю. Обычно все технические ошибки, допущенные на этом этапе, выявляются когда я тестирую процесс один. Логические ошибки находим вместе с руководителями.
Про то, что перед созданием нового бизнес-процесса нужно заручиться согласием всех участников, я уже писал раньше. В принципе, тут то же самое, за исключением того, что в итоге важно перед тем, как запустить новую версию бизнес-процесса, сделать «пресс-релиз» где важно не просто рассказать про изменения, но и сделать сравнение по пунктам «было» и «стало».
Возможно, что я сейчас не рассказал для вас ничего нового, вы знали всё это и раньше, но я буду рад если кому-нибудь это поможет не наступать на мои грабли. Если есть вопросы то задавайте в комментариях.
Для начала нам нужно поверить в то, что любая стабильность относительна, а нахождение в зоне комфорта временное. Сотрудники будут приходить и уходить (даже те, кто сидит на очень хорошем месте), отделы переформировываться, штат увеличиваться и уменьшаться, открываться и закрываться подразделения и т.п. Когда я учился в институте, то преподаватель по сопромату рассказывал нам о том, что при изучении сопромата в России за базу берётся статическое состояние, а потом мы учим динамику, а вот в некоторых других странах за базу берётся динамика, а статика рассматривается как частный случай динамики. Лично мне такой подход нравится больше, он не даёт возможности тешить себя тем, что «сейчас всё устаканилось и ничего меняться не будет». Просто поверьте в это, вам же будет легче потом.
Лирическое отступление: прежде чем рассказывать о том, как писать бизнес-процессы «с задатком на будущее» вы должны для себя прикинуть иерархию вашей фирмы чтобы понять, кто вообще может просить или требовать у вас написать или изменить бизнес-процесс. Один раз ко мне подошёл руководитель одного подразделения и говорит: нам нужен бизнес-процесс для взаимодействия с другими подразделениями, а то у нас всё плохо. А у них реально всё плохо тогда было, даже скорее ужасно. Я три или четыре рабочих дня писал этот БП, сделал почти идеально, а другие подразделения взяли и заявили, что бизнес-процесс этот чушь, не удобный и работать с ним они не будут от слова совсем. Я сижу, не парюсь (это же не моя проблема, там на уровне генерального директора должны были уладить), а потом приходит тот руководитель ко мне и говорит: за работу спасибо, процесс можешь удалять, генеральный позицию тех подразделений принял. И так было много раз по самым разным вопросам и изменениям. С тех пор бизнес-процессы я пишу только тогда, когда директор с этим согласен.
Утром инструкция, вечером блок-схема, а бизнес-процесс завтра
Теперь вернёмся к нашим бизнес-процессам. Иногда они бывают совсем маленькие, буквально на 1-2 клика, чтобы просто зафиксировать то, что кто-то попросил разрешение сделать что-то, а кто-то разрешил, чтобы не бегать с бумажками (и не потерять их). Вроде бы очевидно: подчинённый спрашивает у руководителя можно или нельзя, а руководитель нажимает на соответствующие кнопки. Просто? Да ничего подобного! А если руководителя нет? А если сейчас нужно другого было выбирать? А если был и уехал не подтвердив? А если заполнил не так? А если ещё что-то? А если… И это всё вопросы, с которыми мы постоянно боремся и делаем процесс лучше, но только до тех пор, пока не приходит новый сотрудник. Как приходит то всё начинается заново: те же вопросы, те же ошибки и т.п. Мой руководитель постоянно ругает меня за то, что я делаю мало комментариев и инструкций, но уж очень нравится мне наступать на грабли, а иногда и попрыгать по ним можно. Шучу :-) Теперь я буду поступать иначе: сначала не блок схему (как предлагает руководство пользователя), а обычную инструкцию. Если её все поняли и с ней все согласны, то потом уже рисуем блок-схему и если и с ней согласны, то пишем бизнес-процесс. Это сейчас он может быть маленьким, а со временем может разрастись до такой степени, что вы реально будете обсуждать покупку 4К телевизора с диагональю «побольше» чтобы просто увидеть сам процесс целиком и посмотреть нет ли ошибок хотя бы в логике. Кстати прежде чем приступать к написанию неплохо будет заручиться подписями всех руководителей, чьи подразделения будут пользоваться этим процессом, чтобы потом не было жалоб на неудобную работу, неправильную логику и т.п.
Должность остаётся, а человек меняется
Именно эту фразу я теперь буду ставить во главу угла при написании бизнес-процессов. Действительно практика показывает, что должность есть, просто на ней меняются люди. Как была должность финансового директора, так и есть. Как был главный бухгалтер, так и остался. И руководитель управленческого учёта никуда не делся. А про руководителей отделов продаж я вообще молчу. Другое дело, что должности никуда не делись. Обычно же как: сидишь, работаешь, а тут тебе новость «Маша уходит, Таня приходит». Нужно сразу же судорожно вспоминать в каких бизнес-процессах человек участвует, где нужно одного на другого заменить и т.п. А могут ведь иначе сказать, просто из серии «Маша уходит». Ты человека удалил отовсюду, сидишь себе дома на больничном/в отпуске или едешь куда-нибудь, а тут звонок «у нас тут Таня вышла, только доступа нет почему-то никуда». Ну правильно, её и в Битрикс то не добавили ещё, не то что роли в бизнес-процессах прописали.
Так действительно проще, если думать не о конкретных людях, а о должностях, которые они сейчас занимают. Да, в бизнес-процессе будет 1-2 лишних блока, но зато когда человек поменяется не нужно будет вспоминать где и за что он отвечал, нужно будет просто заменить значение переменной с одного человека на другого и всё.
Правильные права доступа по отделам это очень важно
Гипотетически структура компании полностью вертикальна: Собственник – Директор – Главный бухгалтер – Руководитель отдела – Сотрудник (или как-то так). А может быть горизонтальная: Собственник – Директор – множество отделов. А может быть ещё какая-нибудь.
Раньше я устанавливал права для каждых конкретных сотрудников. Например: есть бухгалтер Лена, она должна видеть все оплаты и отгрузки. Заходим в соответствующие бизнес-процессы и прописываем там нашу Лену. А вдруг её переведут или она уволится? Тогда самый простой способ это давать нужные доступы всем тем, кто находится в группе «Руководители», но это неправильно, поскольку тогда процессы и файлы сотрудников будут доступны не только их руководителям и бухгалтерии, но и руководителям других отделов.
Вариантов тут множество, лично я в последнее время остановился на работе с группами. Создаём группу, добавляем в неё сотрудников (или одного сотрудника) и готово. Больше не нужно переживать по поводу того, что старый сотрудник видит много, а новый мало: просто добавляем в группу или исключаем её. Быстро и просто.
Сохраняем все данные, комментарии и примечания
Если вы идёте к человеку с бумажной служебной запиской, то он не может устно одобрить её, он ставит подпись. Но может устно дать развёрнутый комментарий, в том числе поставить условие вида «я подпишу, но если будет получаться «вот так» то не делай/не покупай». А если подписать нужно у двоих, то, в принципе, можно пересказывать. Именно поэтому нужно сохранять вообще всё и, самое главное, никогда не прописывать «жестко» кто поставил комментарий, а всегда брать из переменной. В первое время я этим очень грешил: где должен директор подтверждать комментарии от его имени, где главбух то от его имени. А потом у людей спрашивают, почему запретили или подходят что переделали, а они и сами не в курсе, что что-то кому-то запрещали :-)
Записываем абсолютно все файлы
Раньше мы записывали только «финальные» файлы, но потом стали не часто, но все же, сталкиваться с тем, что люди начинают спорить на тему «я это не загружал», «когда я подтверждал файл другой был» и т.п. Или вообще стали возвращаться к бизнес-процессу через 2-3 месяца после закрытия.
Тестовые проходы – максимально объемно, но не долго
Буду честным и скажу, что когда ты просишь сотрудников протестировать бизнес-процессы то им плевать. Кому-то лень (хотя сидит ничего не делает), у кого-то нет времени, а кто-то откровенно туповат и не понимает, что нужно делать. Стал тестировать один – неудобно. Стал тестировать со своим руководителем – проще и удобнее, но что ему очевидно другим нет (как я уже писал раньше инструкций-то нет, хотя вроде и очевидно). В результате решили так: я сам прохожу по каждой ветке бизнес-процесса по одному разу, потом тестирую с руководителями всё ли понятно им. Если всё понятно и я объяснил так, что они могут пересказать это своим сотрудникам, то берём по сотруднику от каждого отдела и запускаемся в принудительном порядке (хотя обычно с каждого отдела вполне можно найти добровольца). Если и тут всё нормально, то бизнес-процесс уходит в работу и тут же анонсируем его для всех сотрудников.
Копирование и клонирование процессов
Иногда для ускорения работы над бизнес-процессом беру шаблон старого и правлю его. Так быстрее, но в итоге я получаю:
- неверные комментарии;
- лишние переменные;
- неверные описания задач;
- битые ссылки;
- загрузку файлов не туда;
- не те права доступа;
и ещё много чего такого, чего получить в итоге не хотелось бы. Пробовал писать с нуля – долго и неудобно. Как меньшее из зол выбрал копирование процесса и плавный обход и прочтение каждого блока, чтобы понять правильно ли я делаю. Обычно все технические ошибки, допущенные на этом этапе, выявляются когда я тестирую процесс один. Логические ошибки находим вместе с руководителями.
Вносим значительные изменения
Про то, что перед созданием нового бизнес-процесса нужно заручиться согласием всех участников, я уже писал раньше. В принципе, тут то же самое, за исключением того, что в итоге важно перед тем, как запустить новую версию бизнес-процесса, сделать «пресс-релиз» где важно не просто рассказать про изменения, но и сделать сравнение по пунктам «было» и «стало».
Возможно, что я сейчас не рассказал для вас ничего нового, вы знали всё это и раньше, но я буду рад если кому-нибудь это поможет не наступать на мои грабли. Если есть вопросы то задавайте в комментариях.