Автоматизация предприятия — важнейшая составляющая минимизации расходов. Вопрос даже не в том, что удастся заместить часть сотрудников. Без людей наши компании мало чего стоят. Основная цель — освободить рабочее время, сняв с сотрудников рутинные процессы по перекладыванию бумаг с места на место и дать им простор для профессиональной деятельности.
Классический пример это отдел продаж. При этом неважно, будь то торговая точка или холодные продажи. Мы всегда имеем понятный бизнес-процесс, который можно описать так: контакт с клиентом → продажа → отгрузка. Естественно, что в зависимости от специфики работы компании этот процесс можно усложнять, делать декомпозицию каждого из отрезков, дополнять сбором базы, допродажей, списанием со склада, логистическими операциями и т.д., но самое важное: нельзя исключить ни одного из базовых элементов.
Когда предприниматель понимает, что возникают сложности с учетом, он обращается к интеграторам с просьбой: “Автоматизируйте мне отдел продаж”, и начинается поистине театральное представление. Интеграторы предлагают комплексную автоматизацию, а заказчик отказывается, полагая, что ему пытаются продать дополнительные услуги.
Автоматизация одного департамента из нескольких всегда тормозит работу смежников, так как скорость работы увеличивается, и в рамках старой системы коммуникаций, они не успевают перестроиться на новый ритм работы.
Проблема заключается в том, что предприниматели не видят картину комплексно. Опять же рассмотрим на примере. Если кассовый аппарат просто пробивает чеки, то сначала приходится сводить кассу по контрольной ленте, потом сверяться со складом. При этом, если на складе организована выдача по предъявлению чека, то итог сверки нужно сводить с накладными по закупке. Мы все сталкивались с ситуацией, когда кладовщик на выдаче проводит учет, и параллельно пытается работать с очередью. Неправда ли, в этой ситуации клиенты будут недовольны, а точность учета подвергается сомнению?
Когда ККМ сразу проводит списание со склада, а выдача товара фиксируется, то при учете товара, нужно только пересчитать остатки и свериться с текущим состоянием базы данных.
Таким образом, мы свели сразу два бизнес-процесса — отдельно продажа, отдельно складской учет. Если обмен данными автоматизирован, то сотруднику достаточно закрыть сделку, чтобы запрос на выдачу товара ушел на склад, а продавец занимался следующим клиентом, вместо оформления бумаг. После выдачи товара на складе сразу можно готовить следующий, поскольку списание с остатков так же автоматически оформлено. В этот момент данные по остаткам уже учтены и можно передавать данные в отдел закупок.
Полный цикл бизнес-процессов в предприятии позволяет выявить именно те структурные особенности, которые формирует его облик. При этом задача интегратора избегать лишних элементов процесса.
С точки зрения интегратора, нельзя автоматизировать один отдел. Минимальным объектом может являться только автономная бизнес-единица, включающая в себя весь комплекс процессов предприятия. Впоследствии, систему можно масштабировать, можно реплицировать на другие подразделения и филиалы, но нельзя сделать часть работы и надеяться на положительный результат. Таким образом, просьба предпринимателя автоматизировать какой-то отдельно взятый департамент неизбежно делает работу интегратора бессмысленной и вредной для самого заказчика.
Правильный подход к внедрению CRM
Не секрет, что осознание необходимости внедрить систему управления предприятием еще не означает понимание всего объема предстоящих работ. Давайте рассмотрим, как подходить к вопросу автоматизации до того, как вы обратиться к интегратору.
Чтобы не изобретать новые подходы, предлагаю воспользоваться той же методикой, которую используют сами интеграторы, приступая к новому проекту. Первое, это комплексный подход. Нельзя автоматизировать один отдел и оставить остальные на произвол судьбы. Они должны работать в связке, только тогда мы получим желаемый результат.
Во-первых, необходимо составить список связанных подразделений. В нашем примере это будут:
- Продажи;
- Склад выдачи;
- Закупки;
- Бухгалтерия;
Сформируем цикл бизнес процессов для каждого отдела. Я в нашем примере приведу сокращенные цепочки отношений.
Отдел продаж
Контакт с клиентом → Формирование заказа → Оплата заказа
Склад выдачи
Комплектация заказа по номеру → Проверка при клиенте → Подтверждение выдачи → Подтверждение списания
Отдел закупок
Получение значений по спросу (из отдела продаж) и критическим остаткам (со cклада) →Формирование заказа→ Закупка у поставщика→Постановка инвойса на складской
Бухгалтерия
Получение значений по продажам (из отдела продаж), остаткам (со склада), инвойсам (из отдела закупок) →Синхронизация данных с программным обеспечением и типовыми процессами бухучета.
Далее следует декомпозиция цепочек. Здесь нет единого рецепта, так как каждая компания уникальна, несмотря на схожую деятельность.
Интегратор, в данном случае, не разбирается в деталях и не должен навязывать собственные модели. Он может лишь рекомендовать примеры цепочек процессов исходя из собственного опыта. Одна компания работает с холодными звонками, другая с входящими запросами, третья может комбинировать варианты или быть чьим-либо подрядчиком. Декомпозицию каждого конкретного процесса необходимо делать так, как принято на предприятии и учитывать такие мелочи как изменение статусов, обмен данными или информирование других сотрудников.
Только заказчик знает свой бизнес на этом уровне, и нет единого рецепта, могут быть рекомендованные модели. Но и они не универсальны.
После того как вы описали технологические цепочки и бизнес-процессы, вы можете передать эту схему интегратору. Для начала, он должен создать дерево проекта, в котором наглядно отобразит и согласует с вами все диаграммы, связи и статусы, до мельчайших деталей.
Рассчитывайте, что если процесс или элемент процесса не отражен в проектном плане, он не будет реализован. Учитывайте, что последующие доработки всегда обходятся дороже расчетного бюджета, так как для интеграции новых функций приходится переделывать работающую конструкцию.
После того как вы построили и скорректировали схему проекта, остается чисто техническая работа. Только на этом этапе имеет смысл приступать к выбору программного обеспечения. И самое важное: ни в коем случае не ограничивайте ваши бизнес-процессы возможностями инструмента!
Модное слово Agile: как это выглядит на практике
В последнее время мы все чаще наблюдаем попытки внедрить проектное управление и здесь пути предпринимателей расходятся. Одни предпочитают консервативный PMI, другие гибкие методологии Agile, но на практике получается совсем не то что обещали тренеры.
Дело здесь вовсе не в качестве тренеров или попытках применить западные (в случае с Kanban — дальневосточные) методологии на нашей почве. Проблема кроется в том, что воссоздание внешних признаков методологии далеко не всегда означает ее успешное внедрение на конкретно взятом предприятии, а использование гибкой методологии в консервативных специальностях в принципе ломает устоявшуюся логику бизнес-процессов.
Agile, в понимании большинства предпринимателей сегодня - это доска со стикерами, на которых записаны задачи. Они перемещаются по секторам в зависимости от статуса и процента выполнения. Но сам факт наличия доски не означает внедрения методологии. В результате задачи накапливаются, либо выполняются не те или не вовремя. Это неизбежно приводит к дисбалансу в коммуникациях.
Одни отделы действительно начинают работать эффективнее, но отделы с налаженными бизнес-процессами, наоборот, дают сбои из-за возросшего потока входящих задач от смежников и образуется затор.
Чтобы избежать негативных последствий при внедрении проектного управления, необходимо четко разграничить области применения выбранной методологии. Если рассматривать три основных проектных подхода, мы получим:
Стандарт PMI PMBoK блестяще работает при жестком временном и ресурсном планировании. Если рассматривать области применения, где он реализуется без полутонов и доработок - это конвейерное производство, документооборот с ясными сроками (бухучет, финансовое планирование, регулярная аналитика и формирование отчетности).
Фактически, если мы имеем жестко установленные сроки, применение вех и задач по стандарту PMI более чем оправдан. При этом, если мы можем себе позволить менять задачи местами, начинаются нежелательные для этого стандарта компромиссы.
Agile: SCRUM — отличительной чертой является разделение этапов реализации одной глобальной задачи на “спринты”. Как правило, это двухнедельный временной отрезок, который начинается с постановки потенциальных задач и заканчивается готовым промежуточным продуктом. При этом очередность выполнения задач остается на усмотрение исполнителя, но обязательное условие — достижение поставленной цели к концу спринта.
Методология прекрасно зарекомендовала себя в случаях связанных с IT-разработкой и технической поддержкой, когда мы не можем позволить себе сместить сроки, но высокая вариативность допускает удаление ряда задач, не критичных в конечном продукте.
Agile: Kanban — применяется при штучном производстве и в исследовательских проектах. Гибкая методология всегда имеет цель в виде готового продукта, но не имеет четко обозначенных объемов и сроков. Фактически, если мы знаем перечень участвующих в технологической цепочке элементов, мы выстраиваем их в установленной последовательности, а потом фиксируем результат. Методика требует предельной заинтересованности сотрудников в результате, но становится неэффективной, когда мотивация падает, или нам требуется провести точные расчеты объемов выпуска.
Таким образом, если говорить о типичном предприятии, мы увидим, что невозможно применить любую из методологий в чистом виде.
Предприятие, в котором есть жестко регламентированные отделы, привязанные к календарному расписанию или маршруту (бухгалтерия или курьерская служба) это PMI, отделы с возможностью гибкого управления задачами и привязанные только к конечному сроку (например, техническая поддержка клиентов) это SCRUM, а департаменты ориентированные только на результат (например, разработка новых продуктов) это Kanban.
Следует ли из этого несостоятельность каждой отдельно взятой методологии? Конечно нет! Если взять за основу все три варианта, нам понадобится только внедрить подходящие методологии в соответствующих их концепции отделах и научиться трансформировать результат при передаче из одного отдела в другой.