Битрикс 24 бизнес план

Пишем бизнес-процесс в Битрикс24 с задатком на будущее

На работе я занимаюсь поддержкой пользователей и обслуживанием коробочной версии CRM Битрикс24, в том числе и написанием бизнес-процессов. Нужно отметить, что на самом деле я не «чисто» специалист по Битриксу, а это одна из моих обязанностей. На самом деле обязанностей у меня очень много, поэтому почти всегда делать приходится не как хотелось бы, а быстро и чтобы работало, поскольку времени катастрофически не хватает (я уверен, что в таких условиях работаю не я один). На текущий момент у меня двухлетний опыт работы с этой CRM (с самим Битриксом знаком более 10 лет) и я хотел бы рассказать вам о части ошибок, которые я допустил при написании, тестировании и обслуживании бизнес-процессов, из-за которых мне приходилось и приходится постоянно помогать пользователям, вносить правки, а то и вовсе переписывать бизнес-процессы с нуля.

Для начала нам нужно поверить в то, что любая стабильность относительна, а нахождение в зоне комфорта временное. Сотрудники будут приходить и уходить (даже те, кто сидит на очень хорошем месте), отделы переформировываться, штат увеличиваться и уменьшаться, открываться и закрываться подразделения и т.п. Когда я учился в институте, то преподаватель по сопромату рассказывал нам о том, что при изучении сопромата в России за базу берётся статическое состояние, а потом мы учим динамику, а вот в некоторых других странах за базу берётся динамика, а статика рассматривается как частный случай динамики. Лично мне такой подход нравится больше, он не даёт возможности тешить себя тем, что «сейчас всё устаканилось и ничего меняться не будет». Просто поверьте в это, вам же будет легче потом.

Лирическое отступление: прежде чем рассказывать о том, как писать бизнес-процессы «с задатком на будущее» вы должны для себя прикинуть иерархию вашей фирмы чтобы понять, кто вообще может просить или требовать у вас написать или изменить бизнес-процесс. Один раз ко мне подошёл руководитель одного подразделения и говорит: нам нужен бизнес-процесс для взаимодействия с другими подразделениями, а то у нас всё плохо. А у них реально всё плохо тогда было, даже скорее ужасно. Я три или четыре рабочих дня писал этот БП, сделал почти идеально, а другие подразделения взяли и заявили, что бизнес-процесс этот чушь, не удобный и работать с ним они не будут от слова совсем. Я сижу, не парюсь (это же не моя проблема, там на уровне генерального директора должны были уладить), а потом приходит тот руководитель ко мне и говорит: за работу спасибо, процесс можешь удалять, генеральный позицию тех подразделений принял. И так было много раз по самым разным вопросам и изменениям. С тех пор бизнес-процессы я пишу только тогда, когда директор с этим согласен.

Утром инструкция, вечером блок-схема, а бизнес-процесс завтра

Теперь вернёмся к нашим бизнес-процессам. Иногда они бывают совсем маленькие, буквально на 1-2 клика, чтобы просто зафиксировать то, что кто-то попросил разрешение сделать что-то, а кто-то разрешил, чтобы не бегать с бумажками (и не потерять их). Вроде бы очевидно: подчинённый спрашивает у руководителя можно или нельзя, а руководитель нажимает на соответствующие кнопки. Просто? Да ничего подобного! А если руководителя нет? А если сейчас нужно другого было выбирать? А если был и уехал не подтвердив? А если заполнил не так? А если ещё что-то? А если… И это всё вопросы, с которыми мы постоянно боремся и делаем процесс лучше, но только до тех пор, пока не приходит новый сотрудник. Как приходит то всё начинается заново: те же вопросы, те же ошибки и т.п. Мой руководитель постоянно ругает меня за то, что я делаю мало комментариев и инструкций, но уж очень нравится мне наступать на грабли, а иногда и попрыгать по ним можно. Шучу 🙂 Теперь я буду поступать иначе: сначала не блок схему (как предлагает руководство пользователя), а обычную инструкцию. Если её все поняли и с ней все согласны, то потом уже рисуем блок-схему и если и с ней согласны, то пишем бизнес-процесс. Это сейчас он может быть маленьким, а со временем может разрастись до такой степени, что вы реально будете обсуждать покупку 4К телевизора с диагональю «побольше» чтобы просто увидеть сам процесс целиком и посмотреть нет ли ошибок хотя бы в логике. Кстати прежде чем приступать к написанию неплохо будет заручиться подписями всех руководителей, чьи подразделения будут пользоваться этим процессом, чтобы потом не было жалоб на неудобную работу, неправильную логику и т.п.

Должность остаётся, а человек меняется

Именно эту фразу я теперь буду ставить во главу угла при написании бизнес-процессов. Действительно практика показывает, что должность есть, просто на ней меняются люди. Как была должность финансового директора, так и есть. Как был главный бухгалтер, так и остался. И руководитель управленческого учёта никуда не делся. А про руководителей отделов продаж я вообще молчу. Другое дело, что должности никуда не делись. Обычно же как: сидишь, работаешь, а тут тебе новость «Маша уходит, Таня приходит». Нужно сразу же судорожно вспоминать в каких бизнес-процессах человек участвует, где нужно одного на другого заменить и т.п. А могут ведь иначе сказать, просто из серии «Маша уходит». Ты человека удалил отовсюду, сидишь себе дома на больничном/в отпуске или едешь куда-нибудь, а тут звонок «у нас тут Таня вышла, только доступа нет почему-то никуда». Ну правильно, её и в Битрикс то не добавили ещё, не то что роли в бизнес-процессах прописали.

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

Правильные права доступа по отделам это очень важно

Гипотетически структура компании полностью вертикальна: Собственник – Директор – Главный бухгалтер – Руководитель отдела – Сотрудник (или как-то так). А может быть горизонтальная: Собственник – Директор – множество отделов. А может быть ещё какая-нибудь.

Раньше я устанавливал права для каждых конкретных сотрудников. Например: есть бухгалтер Лена, она должна видеть все оплаты и отгрузки. Заходим в соответствующие бизнес-процессы и прописываем там нашу Лену. А вдруг её переведут или она уволится? Тогда самый простой способ это давать нужные доступы всем тем, кто находится в группе «Руководители», но это неправильно, поскольку тогда процессы и файлы сотрудников будут доступны не только их руководителям и бухгалтерии, но и руководителям других отделов.

Вариантов тут множество, лично я в последнее время остановился на работе с группами. Создаём группу, добавляем в неё сотрудников (или одного сотрудника) и готово. Больше не нужно переживать по поводу того, что старый сотрудник видит много, а новый мало: просто добавляем в группу или исключаем её. Быстро и просто.

Сохраняем все данные, комментарии и примечания

Если вы идёте к человеку с бумажной служебной запиской, то он не может устно одобрить её, он ставит подпись. Но может устно дать развёрнутый комментарий, в том числе поставить условие вида «я подпишу, но если будет получаться «вот так» то не делай/не покупай». А если подписать нужно у двоих, то, в принципе, можно пересказывать. Именно поэтому нужно сохранять вообще всё и, самое главное, никогда не прописывать «жестко» кто поставил комментарий, а всегда брать из переменной. В первое время я этим очень грешил: где должен директор подтверждать комментарии от его имени, где главбух то от его имени. А потом у людей спрашивают, почему запретили или подходят что переделали, а они и сами не в курсе, что что-то кому-то запрещали 🙂

Записываем абсолютно все файлы

Раньше мы записывали только «финальные» файлы, но потом стали не часто, но все же, сталкиваться с тем, что люди начинают спорить на тему «я это не загружал», «когда я подтверждал файл другой был» и т.п. Или вообще стали возвращаться к бизнес-процессу через 2-3 месяца после закрытия.

Тестовые проходы – максимально объемно, но не долго

Буду честным и скажу, что когда ты просишь сотрудников протестировать бизнес-процессы то им плевать. Кому-то лень (хотя сидит ничего не делает), у кого-то нет времени, а кто-то откровенно туповат и не понимает, что нужно делать. Стал тестировать один – неудобно. Стал тестировать со своим руководителем – проще и удобнее, но что ему очевидно другим нет (как я уже писал раньше инструкций-то нет, хотя вроде и очевидно). В результате решили так: я сам прохожу по каждой ветке бизнес-процесса по одному разу, потом тестирую с руководителями всё ли понятно им. Если всё понятно и я объяснил так, что они могут пересказать это своим сотрудникам, то берём по сотруднику от каждого отдела и запускаемся в принудительном порядке (хотя обычно с каждого отдела вполне можно найти добровольца). Если и тут всё нормально, то бизнес-процесс уходит в работу и тут же анонсируем его для всех сотрудников.

Копирование и клонирование процессов

Иногда для ускорения работы над бизнес-процессом беру шаблон старого и правлю его. Так быстрее, но в итоге я получаю:

• неверные комментарии;
• лишние переменные;
• неверные описания задач;
• битые ссылки;
• загрузку файлов не туда;
• не те права доступа;

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

Вносим значительные изменения

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

Возможно, что я сейчас не рассказал для вас ничего нового, вы знали всё это и раньше, но я буду рад если кому-нибудь это поможет не наступать на мои грабли. Если есть вопросы то задавайте в комментариях.

Источник

Разработка бизнес-процесса в Битрикс24. Советы директору

Одна из самых важных (на мой взгляд) функций в Битрикс24 это бизнес-процессы. Теоретически они позволяют вам полностью избавиться от бумажных служебок и перенести их в электронный вид, благодаря чему вы получаете не только экономии бумаги и времени, но и детальную хронологию прохождения процесса (кто и когда запустил, кто во сколько утвердил и т.п.), храните все комментарии и замечания сотрудников, не позволяете людям перескакивать отдельные важные этапы и многие другие плюсы. Так же про определённые вещи можно узнавать не когда всё уже согласовано, а на ранних этапах (например, когда сотрудник собирается в отпуск, запрошена очень большая скидка и т.п.), а не в самый последний момент.

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

Пожалуй, начать стоит с того, что при всём уважении к вам и вашему бизнесу, скорее всего компания 1С-Битрикс в разы больше вашей компании как по штату, так и по обороту, в ней работают более опытные IT-специалисты и, самое главное, они видят сотник таких компаний как у вас и могут читать (ну или не читать 🙂 все пожелания от них. Да, возможно я не прав, и ваша компания крупнее, чем 1С, но тогда вряд ли вы как собственник будете забивать себе голову тем, как же лучше заняться разработкой бизнес-процесса, наверняка у вас для этого есть целый отдел. Если же вы понимаете о чём я, то идём дальше. У Битрикс24 (далее по тексту я буду называть его Битрикс или Б24) есть базовый функционал и вещи, которые он может, а есть вещие которые пока не может или не сможет вообще. Говоря другим языком у него есть ограничения как в техническом, так и в логическом плане. В самосвале сложно возить воду, а на экскаваторе не уложить асфальт (на самом деле своими глазами я видел и то и другое, но, поверьте, зрелище так себе получается, к тому же очень дорого, долго, неудобно, и результат сомнительный). Как бы ни было устроено у вас в компании, к чему бы вы не привыкли, вам нужно будет принять и понять, что некоторые вещи в Б24 сделать нельзя (поскольку мы находимся на Хабре где есть куча гениев и ещё больше высококлассных специалистов, в разы более сильных чем я, то давайте договоримся что фразу «нельзя сделать» мы будет понимать как «нельзя сделать в коммерчески разумный срок» или «у вас на это не хватит денег»).

Начнём с простого: у вас в лексиконе есть фраза «бизнес-процесс», а в Битриксе есть бизнес-процессы, задачи, календари, роботы, триггеры и т.п. Наверняка вы не знаете, чем они друг от друга отличаются, ведь для этого у вас есть сотрудники. Если вы будете постоянно говорить айтишнику о том, что вам нужен бизнес-процесс, то он и будет воспринимать это как требование сделать именно бизнес-процесс в Б24. Я как-то раз больше месяца не мог реализовать требования директора из-за сложности работы и постоянных исправлений, потом всё же пошёл к нему и спросил, почему ему нужен именно бизнес-процесс. В результате разговора выяснилось, что ему нужен не бизнес-процесс, а исполнение его поручения, что позволило моему руководителю уже через час рапортовать ему о том, что поручения исполнены и бизнес-процессы в фирме работают, просто в Битриксе это называется задачи. И знаете что? А ничего. Ему было важно как в фирме работает, а не как в Битриксе это называется. Но это собственник, они никому ничего доказывать не собирается и ни с кем ничем не меряется 🙂 А вот с «руководителями», которые вчера то ли менеджер по продажам неизвестно чего, то ли продавец-кассир в сетевом магазине намного сложнее, понтов и амбиций выше крыши, знаний и опыта ноль, но готовы сожрать и уволить любого, что теоретически может помешать им закрепиться на новом месте. Особенно если понимают что человек их раскусил. Ах, да, я же для руководителей материал пишу: если ваш «управленец» орёт что на прошлой работе «так было сделано и всё работало» не верьте, почти всегда там и близко не было реализовано ничего подобного. Ладно, не всегда, а в 95% случаях там и близко не было реализовано ничего подобного. Почему? Да хотя бы потому, что практически все функции в Битриксе это базовый функционал и для некоторых иная последовательность меню (которая, кстати, пользователем под себя настраивается самостоятельно) это уже «по-другому» или заслуга штатного айтишника.

Усвоили простой урок? Теперь переходим к более сложному: назначьте одного ответственного за процесс, расскажите об этом всем и потребуйте, чтобы все участники процесса подчинялись ему в этом задании. Практика показывает, что обычно задание даётся на группу, а если нет ответственного, то и спросить в случае провала не с кого. Вроде бы все работали, делали дело, а результата нет или он сильно промежуточный (как в анекдоте где есть ещё нельзя, но намазывается уже очень хорошо). Но может быть хуже, гораздо хуже, когда люди возьмутся за дело с душой и огоньком, но при этом видение готового продукта будет разное и оба (а то и все трое или четверо) будут тянуть одеяло на себя, перекраивать под свой отдел и т.п. А исполнитель должен будет разрываться между ними, оказавшись между молотом и наковальней. Если в ответ на это вы скажете что у вас в фирме регламенты такого не позволяют, люди себя так не ведут и всё такое то в ответ я лишь усмехнусь и скажу «ну да, вы же руководитель, до руководителей всегда правду доносят как есть, никогда не врут и вообще мы одна команда».

Кстати после внедрения процесса не забудьте запретить использование бумажных служебок, вместо которых делали процесс. Если вы хоть раз после внедрения процесса воспользоваться бумажкой то всё, не заработает у вас Битрикс никогда, можете сразу выкинуть его вместе с сервером ибо толку теперь ноль. Все, абсолютно все пойдут с бумажками просто потому что:

1. Так проще и быстрее.

2. Если человек идиот и написал бред то руководитель бумажку выкинет и как-будто и не было.

3. «Неправильным» (т.е. не лояльным конкретному человеку, пускай и в ущерб фирме) служебки будут задерживаться максимально долго, подтасовываться очерёдность и т.п.

4. Любой регламент можно нарушить и сначала сделать, а потом согласовать.

5. Когда руководители подписывают бумажку, они могут требовать много чего не относящегося к работе взамен своей подписи, а если в Битриксе служебка повисла на человеке и он не реагирует можно идти выше.

А на самый конец у нас будет самый вкусный кусочек: сколько же вы за это заплатите?

Давайте накидаем примерные зарплаты:

Вы (собственник, руководитель) – 500 000 рублей в месяц.

Коммерческий директор – 80 000 рублей в месяц.

Финансовый директор – 70 000 рублей в месяц.

Административный директор – 60 000 рублей в месяц.

Руководители отделов – по 50 000 рублей в месяц.

Айтишник – 40 000 рублей в месяц.

Пускай в месяце 21 рабочий день, 8 часов. Это выходит, что в месяц человек работает 168 часов. Совещания по нормальному процессу, достаточно сложному идти в присутствии директора (за всё время) меньше часа не будут, а один час собственника, всех директоров, трёх руководителей и айтишника стоит по нашим данным без малого 5000 рублей. Ещё час без собственника и айтишника ещё пару тысяч. Айтишник будет писать, тестировать, настраивать, отлаживать ещё 2 дня и потратит 4000 рублей, побегает к административному директору, к финансовому, к каждому руководителю и т.п., за это вы заплатите ещё не меньше пяти тысяч. Это если утвердят всё и сразу, по факту работы идут с переделками, а совещания дольше. По моим скромным (особенно для крупных городов) оценкам получается, что средней руки процесс будет стоить фирме (т.е. вам) 20-30 тысяч рублей как минимум. Правда вам об этом вряд ли расскажут, но всё же. Потом ещё нужно будет научить всех сотрудников, внести корректировки, объяснить, почему сделали так как написано в техническом задании (которое айтишник писал со слов всех руководителей), а не как им хотелось и т.п. В общем тысяч 40 заплатите и это как минимум. Сюда я свёл официальные и «не официальные» совещания, чаепития и перекуры по этому поводу и тому подобное. Заплатите ли вы эти деньги напрямую? Думаю что нет, все же на окладах. Окупите ли вы расходы? Думаю что да, в некоторых фирмах это не то что за месяц, а за неделю или пару дней возможно, смотря для чего процесс написан (экономия на браке и отсечение необоснованных скидок это тоже прибыль как по мне).

А если нет айтишника? Если его нет, то обычно написание такого бизнес-процесса от 10 000 рублей с учётом вашего технического задания и без кучи дурацких (иначе их не назовешь) доработок. А чтобы потом всё это работало нужно чтобы ваш портал кто-нибудь обслуживал (от 5000 рублей в месяц). А, может быть, за одно только техническое задание вы заплатите 10 000 рублей (конечно же, если речь идёт о написании процесса под вас и ваши нужды, а не продажи копии какого-то процесса под соусом индивидуальности).

Что я хочу сказать в заключении: полноценное внедрение Битрикс24 штука очень дорогая (если вы умеете считать и не врёте сами себе), но нужная и окупающая себя при правильном использовании. Правильно написанный бизнес-процесс может не то что часть работы снять, но и заменить собой сотрудника и даже руководителя (при этом работая без выходных, не отлынивая и действуя строго в соответствии с инструкциями). Может ли такой процесс стоить 5, 10, 25 или 50 тысяч рублей? Лично мне кажется, что честная цена такого процесса от 50 000 рублей только начинается, но поскольку эту сумму вы не платите напрямую, а задействуете сотрудников на окладе, то достаточно просто чтобы они поработали как следует, а не как хочется.

Источник