В виду своей деятельности я последнее время часто сталкиваюсь с необходимостью предложить то или иное программное обеспечение в качестве инструмента для решения разного рода задач. Но подобрать хороший инструмент не так просто. Постоянно получается, что либо инструмент немного не подходит и его нужно допиливать напильником, либо инструмент не ложится целиком в процесс и приходится видоизменять бизнес-процесс для того, чтобы внедрить инструмент.
Тут сейчас могут полететь камни, ведь «проблема может быть в неверно подобранном инструменте», но это не совсем так. Дело в том, что даже если новый инструмент идеально ложится на происходящий бизнес-процесс — всё равно придется делать маленькие видоизменения в деятельности сотрудников, процесс обеспечивающих. Даже если речь идёт о банальной замене ПО, и новое ПО точно такое же, как и предыдущее. Всё равно найдется сотрудник, который скажет, что ему неудобно, «потому что кнопка раньше была в другом месте, а теперь её надо искать», даже если кнопка будет там же — не совпадут цвета и поэтому всё будет отвлекать. Хоть один сотрудник, хоть не на долго — но будет недоволен.
Так что же делать: менять кнопку (читай — допиливать ПО под сотрудников) или не обращать внимания на этого консерватора — привыкнет (читай — менять процесс под ПО)? Это та задача, которая встаёт в любой компании, не зависимо от размера, и я хочу о ней поговорить.
Степени сложности и способы выбора между двумя этими вариантами могут быть разными, в зависимости от:
- Крупности компании (стартап, начинающая, крупная, распеределена регионально, многоязыковая)
- Типа задачи (наладить новый процесс, автоматизировать существующий, оптимизировать существующий) / пометка на полях — Автоматизировать и оптимизировать — не одно и то же
- Специфики компании (большая разница во внедрении внутреннего ПО между государственным учреждением, строительной компанией и IT-структурой)
- Среднего возраста персонала, который будет пользоваться ПО
Наверное, один из самых долгих, дорогих и неприятных случаев — это когда крупной компании с региональным делением приходится для оптимизации процессов менять старые внутренние инструменты на новые. Чем правильнее был выбор на предыдущем этапе роста компании — тем меньше потери (идеальный вариант — когда потерь нет, то есть менять инструменты не нужно, но это труднодостижимая вершина).
Представьте себе ситуацию, что крупной компании с несколькими десятками тысяч сотрудников, распределенной по нескольким регионам нужно сменить один из инструментов, которым пользуются почти все сотрудники. Это может быть какая-то административная панель для ведения внутренней информации, система документооборота, почтовый клиент или, в конце-концов, операционная система. Для того, чтобы перевести всех людей на новый инструмент, нельзя для всех выключить старый и включить новый. Нужно перенести накопленную базу из одного инструмента в другой, постепенно пересаживать персонал в разных отделах, разных офисах, переучивать, править возникающие баги и всё это время поддерживать работу обоих версий инструмента (иногда платить за две лицензии). Иногда возникает необходимость заменить несколько существующих инструментов на один новый, что увеличивает трудности в разы.
Чтобы свести вероятность такой ситуации к минимуму, нужно с самого начала существования компании задумываться о том, что и для чего использовать и какая у этого инструмента перспектива. И большое значение имеет то, как пользоваться инструментом.
Как бы это ни казалось странным, для маленьких коллективов, и стартапов в частности, когда участвуют 2−3 человека, очень распространена модель «я тебе расшарю свой Google Drive и ты там поправишь; а я свою часть на Яндекс.Диск выложил, сейчас расшарю». Когда коллектив разрастается до 15 человек, у этой модели уже существенная проблема в поиске информации. У каждого вроде бы что-то хранится, но при этом найти у кого и что — трудно, нужно потратить на это много времени. Тут возникает первая ситуация, в которой обычно задумываются над выбором инструмента для общей работы над документами, или изменением процесса поведения, или над изменением и того, и другого. Если такой проблемы не возникает — при численности коллектива в 100 человек ситуация будет катастрофична.
Итак, я не очень плавно, но всё же подвёл к задаче правильного выбора инструмента для нового процесса. И задача эта для вновь созданной компании имеет не меньшую важность, чем для крупной, разве что риски для крупной компании выше, пропорционально размеру.
Допустим нам нужно внедрить новый инструмент для абсолютно нового процесса, в новой небольшой компании. Здесь основная задача — это помнить о масштабируемости решения, но абсолютно не стоит забывать о перспективах развития и связных задачах. Пример с Google Drive хорошо говорит про масштабируемость и про то, что нужно не только выбрать инструмент, но и правильно его использовать.
Однако добавлю про перспективы развития на другом примере. Допустим небольшая компания ищет себе систему для работы службы поддержки с клиентами (так называемую тикет-систему — пришло сообщение от клиента, получило номер, когда у сотрудника есть время — он на него ответил). Компания выбирает недорогую или даже бесплатную систему, помня о масштабируемости, и внедряет новый бизнес-процесс.
Через год выясняется, что такого общения клиентам мало, ещё им нужен онлайн-чат, который работает немного по-другому — сообщения копятся в очереди и появляются у оператора, который в статусе «свободен». Однако всех клиентов на этот вид перевести нельзя, некоторым вполне подходит модель общения — «есть время — написал, есть время — прочел ответ». В компании у той же службы появляется второй инструмент со схожей задачей, но с повышенной ответственностью (реагировать на чат надо быстрее). Кроме того, некоторые клиенты, не получив ответ по одному каналу, начинают стучать в другой, чтобы разобраться в проблеме, нужно искать предыдущие запросы в другой базе.
Потом компания доходит до уровня телефонной поддержки, но не забывает про своих клиентов, которые попросту не любят говорить по телефону — им проще писать. Назревает либо внедрение третьего инструмента, либо замена предыдущих двух на более совершенный с миграцией базы и всеми вытекающими.
Однако если бы вначале подумали о перспективах развития поддержки клиентов — могли бы сразу выбрать инструмент, который позволит безболезненно подключить новый канал, а не только масштабировать количество пользователей. При этом цена такого инструмента без дополнительных модулей, на начальном этапе может не отличаться от более подходящего. А вот переход с трех разных инструментов на один — будет болезненным и дорогим.
Теперь про связные задачи.
Не будем далеко ходить и представим ту же компанию со службой поддержки. Предположим, что эта компания занимается поддержкой своего оффлайн продукта, а продукт продает через интернет-магазин, и в компании есть своя служба логистики. Так вот у службы, которая принимает заказы в интернет-магазине, как правило своя система учёта заказов и действий с ними. Ну и правильно, логично. Разные задачи — разные системы. Свой отдельный администратор, который обеспечивает стабильность работы системы, обучение новых пользователей и общую поддержку, свой отдельный программист, который дорабатывает систему под нужды пользователей.
Потом у компании возникает необходимость сделать рассылку писем о бесплатном ремонте некоторых устройств, и те, у кого серийные номера устройств совпадают — должны ответить на письмо, и оно должно тоже иметь свой номер и историю сообщений. Компания ищет очередной инструмент и снежный ком продолжает расти. Компания увеличивается, создает подразделения в регионах, численность заказов и инструментов тоже увеличивается, растут уже не программисты и администраторы, а целые отделы по обслуживанию внутренних инструментов.
Однако существуют системы, которые не являются сильно сложными, дорогими, но при этом прекрасно выполняют все три задачи, просто под каждую задачу эту систему нужно немного настроить, иногда доработать.
Тут встает важный вопрос: а стоит ли кидать все яйца в одну корзину? Разные отделы — разные задачи, разные инструменты. Такой подход тоже возможен, но довольно часто разница между процессами не так сильна, чтобы заводить отдельный инструмент. А чтобы не мешать всё в одну кучу — можно разносить базы или даже копии одного и того же инструмента на разные сервера. Только при этом можно экономить на специалистах по разным инструментам, на администраторах, иногда экономить на лицензиях.
Но всё же быть такого не может, что все эти задачи решатся одним инструментом именно так, как их можно решить инструментами, специально подобранными под решение конкретной задачи… И вот тут встаёт главный вопрос: что же лучше — переделывать процесс под инструменты или править инструменты под процесс?
Очень распространенное и при этом ошибочное мнение, что если дать людям инструмент, алгоритмы которого заточены под выполнение задачи в определенных рамках — то бизнес процесс будет выполняться в этих рамках. Особенно часто такое мнение встречается у руководителей, которые не очень хорошо представляют себе процесс автоматизации. В этих случаях, как правило, руководители имеют своё собственное представление об идеальном процессе и считают, что даже если сейчас процесс организован как-то по-другому, то после внедрения инструмента, загоняющего людей в рамки — ситуация изменится. Это не так.
Люди работающие на местах будут оптимизировать процесс под свои привычки и выйдут за рамки, объясняя себе это тем, что у инструмента нет достаточного функционала, чтобы покрыть их задачи. В таком случае использование нового инструмента будет сводиться к минимуму, а у руководителя будет складываться мнение, что он потратил деньги на неправильный инструмент.
Приведу пример. В компании делают заказы на канцтовары раз в неделю. Начальник каждого подразделения в среднем раз в неделю присылает письмо в котором список необходимых товаров. Офис-менеджер собирает письма от начальников, пересылает их на склад в другом конце города, откуда привозят канцтовары (ну очень много канцтоваров в неделю использует компания). В конце каждого месяца сотрудники склада смотрят остатки на складе и дозаказывают то, чего нет на складе.
Руководитель зная этот процесс хочет исключить из этой работы офис-менеджера, автоматизировать процесс и получить аналитику по тому в каком отделе и что активнее используется.
Офис-менеджер показывает стандартное письмо, которое пишет на склад раз в неделю, дает комментарии и на этой основе делают стандартную форму заказа: ручка, линейка, бумага, карандаш, ластик, нож канцелярский, ножницы.
Сотрудникам склада объясняют, что теперь будет приходить не письмо, а будет открываться форма, в которой будет написано что именно привезти. Начальникам раздают логины от нового инструмента и говорят, что теперь они будут заказывать не письмом, а выбирая из формочки. Так проще, чем каждый раз писать и офис-менеджер свободен. А чтобы сотрудники склада ездили, только когда накопится большой заказ — устанавливают ограничение, которое открывает заявку на складе только после того, как заказали все начальники подразделений. В общем всё просто, логично и удобно. Систему запускают.
Но на самом деле выясняется, что начальники подразделений не сами делали заказ, а просили своих подчиненных писать им письма, кому и что нужно, потом копипастили их и отправляли всё письмо офис-менеджеру, она из всех писем собирала одно большое и отправляла его на склад. Теперь начальники не могут копипастить письма, так как им нужно выбирать необходимое из выпадающего списка, а на это у них нет времени. Поэтому начальники раздают свои логины и пароли от сервиса подчиненным и говорят заказывать через форму.
Кроме того выясняется, что такая периодичность была потому, что начальники не часто находили время, чтобы собрать из всех писем подчиненных одно большое и выбирали для этого кто среду, кто четверг, поэтому к пятнице всё было готово. Но подчиненные писали начальникам когда удобно: кто в понедельник, кто во вторник, кто в пятницу, в общем круглую неделю. Таким образом, в каждом подразделении находятся те, кто делает заказ и в понедельник и во вторник. А так как логины и пароли у подчиненных от учеток начальников, то на складе каждый день появляется новый заказ, причем довольно маленький.
Кроме того выясняется что в форме отсутствует любимый одним из отделов «карандаш с ластиком», когда делали форму по консультации с офис-менеджером — в форме остались только карандаш и ластик. В форме нет того что нужно, и сотрудники звонят на склад и говорят: мы тут заказали вот то, но на самом деле это другое или хуже: мы заказ скинули, но там не всё. Сотрудники склада принимают заказ, но созваниваются с сотрудниками и договариваются приехать в другой день и привезти чуть больше, чтоб на дольше хватило.
Таким образом из-за того что запускали инструмент основываясь на недостаточной экспертизе, вместо упрощения жизни для всех — более-менее устоявшийся процесс превратился в беспорядочный. Статистику не собрали, работу усложнили, деньги потратили.
Для того чтобы таких ситуаций не возникало перед внедрением новых инструментов необходимо сделать три вещи:
- Не основываясь на знаниях алгоритмов работы какой-либо системы, описать идеальный алгоритм бизнес-процесса, который видит себе руководитель.
- Узнать у всех работников, которые будут обслуживать бизнес-процесс, как они видят себе алгоритм работы (стопроцентно алгоритм будет выглядеть несколько иначе).
- Нужно определить те точки, в которых видение процесса расходится.
- Нужно провести совместное обсуждение по каждой точке расхождения и принять совместное решение о том, как наиболее правильно действовать в той или иной ситуации.
На выходе будет получена карта того, как этот процесс действительно будет работать в компании, а не карта личных представлений отдельных людей. И только под эту карту нужно подбирать необходимый инструмент.
Как говорилось ранее — скорее всего, не один инструмент не будет идеально ложиться на эту карту, поэтому следует:
- Записать точки возможного расширения задач и смежных задач, которые могут быть решены необходимым инструментом.
- Провести анализ инструментов и пометить точки несоответствия в алгоритмах инструмента и алгоритмах полученного бизнес-процесса.
- Выяснить у разработчиков подходящих решений возможности изменения логики работы под нужды организации, цену этих изменений и риски, к которым такие изменения могут привести.
- Провести совещания с сотрудниками, обеспечивающими процесс в контрольных точках, и узнать, готовы ли они адаптировать свою работу под существующие ограничения и какие риски в этом видят они.
На выходе получится список инструментов подходящих для решения задач и список рисков в каждой из контрольных точек. И только имея на руках подобную карту алгоритма действия со списками рисков, нужно принимать решение по внедрению того или иного продукта.
Казалось бы список действий слишком обширный и для решения маленьких прикладных задач не стоит тратить так много времени, но в противном случае вы рискуете получить неработоспособный и ненужный инструмент.
