ТОиР без бумаги: как не терять заявки на ремонт
Как перевести заявки, регламенты и дефектные ведомости в систему, чтобы простои считались.
Читать →Что сделать до старта, как разбить работы на этапы и на чем проекты чаще всего срываются.
Проекты внедрения редко проваливаются из-за техники. Настроить систему умеют многие, а довести до состояния, когда ею действительно пользуются, получается не у всех. Ниже — план, по которому мы работаем, с честным указанием мест, где обычно все и ломается.
До разговора о платформе нужно ответить на один вопрос: какой процесс мы меняем и по какому признаку поймем, что стало лучше. Не «внедряем CRM», а «хотим, чтобы ни одна заявка не висела без ответа дольше рабочего дня, и чтобы руководитель видел это без обзвона».
Формулировка в таком виде решает сразу две задачи. Она позволяет ограничить объем работ — понятно, что входит в первый этап, а что подождет. И она дает критерий приемки: через квартал можно посмотреть на цифру и сказать, получилось или нет.
Практический совет: берите один процесс, максимум два смежных. Попытка автоматизировать всю компанию сразу удлиняет срок в разы, а первого результата не видно месяцами — и проект теряет поддержку внутри до того, как что-то заработает.
Это тот пункт, который чаще всего пропускают, и он же чаще всего убивает проект. Нужен человек, который принимает решения по процессу, имеет право менять правила и договариваться с подразделениями. Не системный администратор — у него нет полномочий сказать начальнику цеха, как теперь оформляются заявки.
У этого человека должно быть выделенное время. Внедрение — не фоновая нагрузка: нужны встречи, разбор спорных случаев, приемка этапов, разговоры с недовольными сотрудниками. Если ответственный может уделять проекту час в неделю между всем остальным, срок можно смело умножать на два.
Дальше подрядчик разбирает, как работа устроена сейчас: кто инициирует, кто согласует, где данные, где все зависает. Важно описывать фактическое положение дел, а не регламент — расхождение между ними обычно и есть корень проблемы.
На этом шаге полезно собрать:
Занимает такой аудит обычно от нескольких дней до пары недель в зависимости от размера. Экономия на нем выглядит выгодной ровно до момента, когда на этапе настройки выясняется, что у половины подразделений процесс устроен иначе.
Отдельный шаг, который любят откладывать. Номенклатура с пятью названиями одной позиции, дубли контрагентов, остатки, которым никто не верит, база клиентов с телефонами в трех форматах — все это переедет в новую систему вместе с проблемами и сделает ее такой же ненадежной, как прежние таблицы.
Полностью вычищать историю не нужно, это отдельный долгий проект. Достаточно привести в порядок справочники, с которыми пойдет ежедневная работа, и перенести данные за разумный период. Остальное остается в архиве.
Хороший план внедрения выглядит как несколько этапов, у каждого — свой результат, который можно показать и принять. Плохой — как один большой блок «настройка системы» со сроком в конце квартала.
Рабочая разбивка обычно такая:
Каждый этап заканчивается приемкой: заказчик видит результат и подтверждает его. Так проект не превращается в бесконечную настройку, а оплата идет за принятую работу.
Запускать сразу на всю компанию рискованно. Разумнее выбрать одно подразделение или одну категорию операций и поработать так пару недель. За это время вылезают все несостыковки: поля, которые никто не заполняет, маршрут, который не учитывает отпуск согласующего, шаг, о котором забыли рассказать на аудите.
Обучение стоит разделить по ролям. Тому, кто заводит заявку, нужно двадцать минут и одна форма. Тому, кто работает в системе весь день, — полноценное занятие и инструкция под рукой. Руководителю — показать два отчета, по которым он будет спрашивать с людей. Общая лекция на всех одинаково бесполезна для всех.
Отдельно предупредим: в первые недели работы становится больше. Люди учатся, ошибаются, ворчат и просят вернуть таблицы. Это нормальный этап, а не признак провала, но его нужно закладывать в план и в ожидания руководства. Как мы учим сотрудников, описано отдельно.
После запуска правила почти всегда донастраиваются: что-то оказалось лишним, что-то не предусмотрели. Разумный период плотного сопровождения — месяц-два, дальше система живет в обычном режиме.
Тогда же имеет смысл смотреть на следующий процесс. Он выбирается сам: это контур, который упирается в соседний. Продажи упираются в остатки — значит следующим идет склад. Склад упирается в поставки — значит снабжение.
По срокам ориентир такой: базовый контур одного процесса — недели, полный проект со связкой нескольких направлений и обменом с учетной системой — месяцы, но не годы. Если подрядчик называет срок в полтора года без промежуточных результатов, спросите, что вы увидите работающим через первый месяц. Как мы ведем такие проекты, описано в разделе о компании.
Разберем, что автоматизировать первым, разложим работы по этапам с приемкой и назовем сроки. Аудит бесплатный.
Как перевести заявки, регламенты и дефектные ведомости в систему, чтобы простои считались.
Читать →Разбираем на своем проекте: крюинговая компания с Крюинспектора на Битрикс24. Шаги, сроки и риски.
Читать →Семь причин расхождения остатков — от приемки задним числом до пересортицы — и что с каждой делать.
Читать →Что синхронизировать, кто становится главной системой и что делать с ошибками обмена.
Читать →