Артём Колисниченко: Сегодня в рубрике “Рассказ от первого лица” уже знакомый вам Сергей Улаев, руководитель компании AffContext, рассказывает о том, как внедрялся ПланФикс в компании, которая занимается производством одежды под своим брендом. Нас часто просили показать конкретный пример внедрения именно на производстве. И вот хороший пример, который можно повторить на любом (ну, или почти любом) предприятии. Передаю слово Сергею.
«Было бы счастье, да несчастье помогло»
(девиз внедрения системы на проекте)
Сергей Улаев: Данная история в очередной раз покажет мощь ПланФикса на примере компании, которая занимается производством одежды под своим брендом. И увы, мы не сможем показать все 100% возможностей системы, ибо вы просто устанете это читать, но самое важное мы точно покажем. Цитата, указанная в самом начале, отлично показывает ценность системы для клиента.
Внедрение ПланФикса началось в феврале 2020-го года, когда карантин уже вступил в Россию. Скоро всё закроют, скоро всех посадят по домам и надо будет как-то дальше продолжать работу. ПланФикс оказался как никогда кстати, это понимали и сотрудники, и сам клиент. Ну и мы, конечно :). «Несчастье» в виде карантина привело к тому, что у коллектива не было иного варианта, как работать в системе, сидя по домам. И это прекрасно.
Что ж, начнём описание прелестей системы. Пару слов лишь скажем о том, что такое серьёзное внедрение, описанное здесь, всегда предполагает этап аудита бизнес-процессов, где рисуются разные схемы текущего взаимодействия коллектива. Потому что только так можно понять, какую систему вообще предстоит реализовывать.
Выглядеть это может, к примеру, так:
Но чаще намного объёмнее :).
Итак, старт внедрения. Как же его грамотно организовать в системе?
Мы вот безумно любим ПланФикс за возможность внедрять функционал поэтапно. Это очень-очень-очень крутая возможность, помогающая коллективу максимально комфортно вливаться в работу с системой. На эту тему у нас даже есть отдельная статья, советуем её тоже к изучению – «При внедрении CRM не надо садить коллектив сразу в кабину Боинга». В ПланФиксе есть для этого незаменимый функционал под названием «Рабочие пространства». «Каждому – по потребностям» – кричал лозунг коммунизма. А мы кричим «Каждому – своё рабочее пространство!». Но при этом «своё – не каждому» :). И это прекрасно позволяет сделать нужное разграничение прав доступа, но об этом дальше.
Итак, задача № 1 – сделать минимально…минимально…МИ-НИ-МА-ЛЬНО необходимый внешний интерфейс системы для каждой группы сотрудников. Хотя в данном случае получилось, что стартанули все с одинаковым внешний интерфейсом (хоть и каждый под своим пространством), просто дальше оно развивалось у каждого по-своему. Выглядело это очень пусто (что и круто) лишь с 3-мя возможными ссылками для нажатия:
Придерживаясь нашей идеологии, мы НЕ делаем внедрение всего функционала. Сотрудники просто охренеют и повешают на балконах своих домов флаги «Мы против ПланФикса!». А мы этого не хотим :). Поэтому мы ещё на этапе аудита выявили самый важный, но при этом довольно независимый функционал, который можно завести в систему. «Независимый» означает, что вот это они могут делать в системе, а всё остальное – ЗА рамками системы без лишних прыжков «туда-сюда». И это были 3 запроса:
- Запрос на оплату счета
- Запрос на логистику
- Запрос на закупку
Вот только их и можно было «заказать» в системе. Объяснение этого функционала заняло минут 20, что очень допустимо, т.к. люди это реально могут запомнить. Набор полей для заполнения по каждому запросу был даже интуитивно понятен. Например, для закупки это выглядело так:
Мы убрали все лишние поля, оставив лишь самое нужное и дав сотрудникам всего лишь одно главное правило – «Заполняете те поля, что видите». Потому что в скрытых плашках был свой набор системных полей, которые не надо зрительно видеть человеку при создании задачи.
На этом этапе человек мог видеть лишь те задачи, где он постановщик или исполнитель. В табличной форме. Спустя несколько дней, когда люди усвоили работу с этим предельно простым функционалом, мы выкатили следующий – хроника событий. И теперь надо было собрать все задачи и хронику в одном месте – планировщике. Это стало выглядеть уже вот так:
А чтобы вернуться назад, к табличному отображению задач, можно было кликнуть вверху на меню «Задачи». Кстати, в этот момент мы и добавили новый пункт для создания задачи – Операционная задача. Это задача на всё, что угодно, кроме описанных выше. Хоть на пойти вниз и покурить с кем-то из сотрудников.
Маховик внедрения системы успешно запустился. Коллектив начал активно создавать в системе задачи, при этом продолжая бОльшую часть своей работы и общения делать вне системы. Пока что. Но теперь в системе, с появлением хроники, уже можно было понимать, к примеру, когда была закрыта задача логистики, что они заказали. Больше не надо было дёргать логиста этими вопросами.
Но если вы только знакомитесь с системой, и вам на глаза попалась данная статья, то вам обязательно надо показать, как бы выглядел интерфейс системы без настройки рабочих пространств. Именно так он выглядит при входе в систему:
Не зная всей мощи системы, можно ужаснуться и подумать, что это всё сложно. А зря. Ну…хотя как зря. Это тоже надо знать, как делать, надо лишь разобраться. Но копаться в коде и обладать навыками программирования вам для этого не надо. Зато теперь вы знаете, что всё это можно исправить.
Задача № 1 выполнена, стартовый интерфейс настроен. Мы в этот момент в своей голове уже «видим будущее», уже знаем: где, как и что будет дополняться по новому функционалу. И как будет выглядеть интерфейс. Знание будущего – это прекрасно :).
Пора приступать к задаче № 2 (а точнее она внедрялась параллельно с первой) – это настроить процесс коммуникации сотрудников с нами – компанией-интегратором. Обычно на рынке это делается в стиле «есть запрос – создавай задачу в систему», но тут мы пошли другим путём – более простым и понятным для человека, который привык общаться в чате. Мы сделали чат для общения с каждым сотрудником компании. Просто чат – это та же задача :). У сотрудника это выглядело так:
Сотрудник же мог перейти в свою задачу-чат из любого места в системе, кликнув на значок «избранное» в поисковой строке:
Упс, тут вы увидели интерфейс меню из «будущего» этой статьи, ну да ладно. Пусть будет интригой :). Для нас же, как интеграторов, это был набор задач по общению с каждым сотрудником компании клиента:
Данная система общения отлично себя зарекомендовала и была предельно понятна каждому сотруднику. Чат есть чат. К позадачному методу создания задач на каждый запрос мы в итоге придём, но сильно позднее, когда коллектив уже прочно будет сидеть «на игле» ПланФикса.
Что ж, перейдём теперь к описанию части огромного функционала, что в итоге был реализован. Например, почти сразу после работы в системе нам начали поступать запросы, что логист не видит контактные данные людей, кто будет принимать / отправлять груз. А по логике распределения прав доступа логист не видел все контакты в системе. Поэтому за счёт взмаха волшебной палочки и подкручивания шестерёнок в наших мозгах «родился» функционал, который после создания запроса на логистику в нужное поле клал всю необходимую информацию по контактам на погрузке и разгрузке:
Ведь логисту нужно было видеть лишь имя и телефон, всего прочего по контакту ему для работы и не надо было. Вот мы и сделали вывод лишь этой информации в задачу логистики, автоматически, без лишних действий со стороны постановщика этой задачи. При этом логист так и не имел в этот момент доступа к самому контакту со всеми его другими данными.
К этому моменту подошла пора переносить имеющуюся информацию из текущей CRM системы клиента (хотя сложно это назвать для нас CRM) в ПланФикс. Клиент использовал Trello, и там были заведены карточки по новым моделям в разработке. Надо было перенести их в систему, снабдив всей необходимой недостающей информацией внутри самой карточки модели. Так это выглядело в Trello:
А вот так это выглядит в ПланФиксе:
С виду также, но вы ещё не знаете, какой мощный «двигатель» появился у всех этих задач после переноса в систему :).
Кстати, вы заметили, что в интерфейсе появилось новое меню «Разработка»? Оно выпадающее и даёт возможность быстро попасть в нужную группу задач по разработке. Мы продолжаем придерживаться нашего подхода «нужный функционал подаём вовремя», постепенно расширяя рабочее пространство нужного сотрудника нужными вещами. При этом другие сотрудники не видят у себя это меню «Разработка». Ну не магия ли? 🙂
Примерно в этот момент мы получаем первый живой отзыв от сотрудника по использованию системы:
Для нас видеть такое – это как бальзам на душу. Значит наше дело верное и ценное. Также в это время мы начинаем процедуру по переносу данных в систему по всей номенклатуре клиента. Это отдельная «больная тема», на которую у нас есть отдельная статья. Крайне рекомендуем её тоже к изучению, она поможет вам избежать многих ошибок и вообще сильно повысит шанс успешного внедрения системы для вашей компании – «Что такое “Подготовка данных к переносу” в строке сметы на внедрение системы управления проектами». Поэтому об этом тут писать не будем, всё есть в статье по ссылке выше.
Хотя… нет. Дадим всё же 2 общих скриншота про процедуру переноса данных. Она заключается в том, что надо вот это…
Привести к такому виду:
И если вы думаете, что это «пф, делов-то», то вам точно надо прочитать нашу другую статью и да пусть ваше понимание в этой области теперь будет более качественным :). Но лучше оставьте это дело после прочтения этой статьи, все прочие ссылки будут также представлены в самом конце этой статьи.
Мы пойдём дальше описывать возможности системы по этому проекту.
Нельзя обойти стороной возможность автогенерации документов в нужный момент времени. Причем сам процесс генерации документа тоже будет запущен автоматически. Например, в нашем случае при создании задачи утверждённого плана на пошив система сама генерирует документ с информацией по всем моделям, что надо отшить. На момент внедрения этого функционала файл выглядел так:
А в задаче это выглядело так:
Ах да, ещё на скриншоте выше вы можете видеть первый комментарий, который тоже отправляется автоматически при создании задачи. Т.е. в какой-то момент времени сотрудник лишь жмёт на кнопку «Утвердить план на пошив» и там пошлааааааа целая комбинация автоматик:
- Создается задача утвержденного плана на пошив.
- Генерируется файл плана на пошив.
- Уходит письмо на производство с утвержденными сроками производства.
- Создаётся задача на печать лекал.
- Создаётся…
Ой, последние 2 пункта уже тоже из будущего. Не будем пока и вас перегружать информацией. Просто знайте, что по нажатию одной кнопки срабатывает целый ворох автоматических действий, которые раньше надо было делать вручную. И то, если вспомнить об этом – с чем тоже порой были проблемы.
Идём дальше.
Чаще всего любую задачу в системе можно решить разными способами, используя разный функционал. Наша задача же – знать, в какой момент какой функционал дать (чтобы попроще было). А потом в нужный момент заменить его на более функциональный (чтобы больше возможностей было). Так, например, у нас получилось с занесением кучи информации по новой модели:
- Вид ткани
- Цвет ткани
- Артикул цвета ткани
- Особенности ткани
- Этикетка
- И пр…
Изначально мы сделали добавление этой информации предельно простым образом для сотрудника – в нужное поле в задаче пиши нужную информацию:
Все эти поля были добавлены нами, как пользовательские поля ПланФикса. Как только сотрудники освоили этот метод, мы сделали занесение той же информации по-другому, уже через т.н. аналитики:
Суть та же, информация та же, но возможностей сильно больше. Например, после этого действия у нас появилась возможность автоматически формировать ещё один документ – описание модели, готовой к запуску. Кусочек этого документа показан ниже:
Напомним, ВСЁ показанное выше формируется а-вто-ма-ти-че-ски. Ранее, чтобы получить эту информацию, надо было сделать несколько запросов нескольким людям. А теперь всё в одном месте.
По хронологии развития событий где-то через пару недель после внедрения массового карантина по стране мы получаем живой отзыв об использовании системы и от самого руководства. Ещё один бальзам на душу:
Двинули дальше.
Обязательно стоит отметить наличие возможности не только генерировать документы, но и генерировать нужные сообщения внутри системы нужным людям в нужные моменты времени… от имени бота :). Например, здесь бот по имени «бот Джо» просит исполнителя задачи приложить файл Торг-12. А исполнитель отписывает, почему он не может это сделать, дав нам ценную информацию о том, что что-то здесь нужно поправить:
Мы довольно сильно пользуемся такими автосообщениями, они помогают коллективу помнить важные вещи в нужные моменты при работе в системе. Особенно при первом этапе внедрения. Например, тут при создании задачи разработки автоматически уходило сообщение о недавно реализованном функционале:
Через месяц мы отключили это оповещение, но за этот месяц оно сыграло очень хорошую свою роль. Ну да давайте отойдём от темы автоматики и рассмотрим немного работу с самими задачами.
Одно из важных правил, которое мы внедрили (с большим трудом, но всё же) – это чтобы у каждой задачи была своя надзадача. Ну… как бы вам объяснить. Вот если запрос на логистику, то он относится к какой-то модели. А если это готовая модель, то должна быть задача на разработку этой модели. И вот надо эту логистику как-бы «привязать» к задаче разработки модели. То же самое касается и простых операционных задач – они все всегда касаются какой-то модели. И когда всё лежит «по полочкам», то получается настолько идеальная картинка, что можно зайти в любую задачу и сразу понять, что происходило по ней и что происходит сейчас (ну жаль вот только в будущее не заглянуть).
Например, на скриншоте ниже видно, что по новой модели уже было несколько задач пошива, пара задач логистики, печати лекал, подбора ткани. А также видны текущие активные задачи:
Всё в одном месте, как на ладони. Причем мы в системе сделали так, что нельзя закрыть основную задачу (надзадачу), пока не будут закрыты все подзадачи. Ох сколько непонимания это вызывало на стороне коллектива (да и вызывает до сих пор), но у этого есть чёткая логика, которой мы, как интеграторы, придерживаемся. А суть её в том, что система должна помогать выполнять работу не одного конкретного человека, а всего бизнес-процесса в целом! Это очень-очень важный момент. Всегда сотрудник хочет быстрее закрыть свою задачу.
Заносить внутрь информацию? Да зачем, у него итак других задач полно. А потом оказывается, что не занеся в моменте информацию, она может понадобиться (как всегда в самый неудобный момент) другому человеку, и уже ему понадобится потратить время на получение нужной информации. В итоге общее время на разработку новой модели (к примеру) будет растягиваться.
Но как только все начинают заносить информацию о важных вещах в систему, она становится общедоступной (ну в рамках той дозволенности, которую мы сами и определяем через права доступа) нужным людям и общая скорость получения конечного результата для компании сильно возрастает. Поэтому если сотрудник хочет закрыть задачу, когда есть открытая подзадача (пусть и не его) – то система ругается и не даёт это сделать. И нашим запретом мы вынуждаем сотрудников «пинать» других сотрудников, чтобы те быстрее сделали свои задачи. Или иначе эта задача будем мазолить вам глаз. А никто не хочет видеть у себя те задачи, которые уже завершены.
Техническая реализация такой структуры задач не требует какой-либо настройки, это идёт из «коробки» функционала ПланФикса. Отдельная тема – организационное внедрение такой привычки у коллектива. Вот там затрат мама-не-горюй. Ну да не будем об этом тут. Потому что об этом можно прочитать в ещё одной нашей статье про этот же проект. Только если здесь мы описываем проект с технической точки зрения, то там идёт художественное описание того, как мы решали больше организационные проблемы внедрения. И тоже советуем вам её прочитать, чтобы вы вообще понимали, что НЕ на одних знаниях функционала системы строится успех внедрения. Там по ходу столько организационных проблем приходится решать… В общем, вот статья – «Внедрение ПланФикса для производства одежды в период коронавируса».
Хотя вот запрет на закрытие задачи с открытыми подзадачами – это всё таки была настройка внутри ПланФикса :).
Поезд разработки разгоняется, и система обрастает функционалом. Вот уже мы начинаем видеть все задачи для швей и понимать, что что-то у нас долго не проверяется продукция – целых 17 моделей уже отшиты, но так и не проверены:
Как обычно, можно зайти в любую задачу, перейти в её надзадачу (родительскую задачу) и увидеть всю история взаимодействия по модели.
Не весь функционал, который мы технически делали, сразу находил «любовь» у сотрудников. Каким-то откровенно не пользовались, т.к. тому были свои организационные проблемы, но об этом не здесь, об этом будет в другой статье (все ссылки будут в конце этой).
Мы можем бесконечно долго описывать весь технический фарш того, что было настроено. Но давайте ещё опишем немного и самое базово-интересное для вас, как руководителя компании или того, у кого стоит задача поиска системы управления проектами для вашей компании.
Фильтры задач
То, без чего вообще не представляем работу в системе. Только оцените, сколько их получилось спустя полгода внедрения системы:
И туда не всё влезло ещё. Фильтры задач позволяют среди общего потока происходящего внутри компании вычленить именно нужные задачи и быстро оценить обстановку. Или же перейти в нужную задачу, чтобы получить нужную информацию.
Настройка рабочего пространства
Покажем на примере сотрудника из отдела разработки новых моделей. Помните, каким был интерфейс при старте внедрения? А теперь оцените, какой он стал спустя полгода работы:
Это сфотошопленная картинка, где мы сделали отображение всех выпадающих менюшек, чтобы вы могли оценить, насколько увеличился арсенал работы сотрудника в системе. Это уже не 3 простых запроса, тут уже можно в несколько кликов перейти в любую нужную задачу из сотни текуще-активных. И уже вся работа теперь идёт в системе.
Настройка внешнего вида любого шаблона задачи
Через полгода работы, когда в компании уже появился «ген» работы в системе, мы упразднили общение с сотрудниками через их задачу чата и ввели систему позадачного обращения. Для этого настроили предельно простой шаблон создания задачи:
Никаких лишних полей, только самое важное. И таким образом можно настроить отображение нужных полей в любом шаблоне задач.
Автоматические действия
О, их тьма (88). Все не будем описывать, но вот вам список наиболее интересных, чтобы вы могли оценить техническую мощь системы при работе с задачами:
- Уведомляем сотрудника, если он удалил задачу (это под запретом, чтобы не терять никакую информацию).
- Не даём закрыть задачу, если у неё есть активные подзадачи (писали об этом выше).
- Автоматическое формирование названия задач.
- Если закрылась задача закупки (с нею работает закупщик), то автоматически закрываются все связанные задачи запросов на закупки.
- Не даём закрыть задачу разработки, пока не будут корректно заполнены все необходимые поля.
- Автогенерация разных документов и автоотсылка их нужным внешним контрагентам.
- Автоматическое создание задачи на проверку расхождений поставки, если закрылась логистика определённого направления.
- Автоматическое оповещение отдела контроля качества о том, что нужно проверить продукцию, в момент, когда закрывается логистика именно тестового образца по новой модели (вы только оцените, к каким хитрым событиям привязана эта автоматика!).
- Подтверждение у гл. закупщика запроса на оплату счета в случае, если запрос сформирован мл. закупщиком.
- Автоматическое создание официального письма для производства, когда утверждены сроки производства.
И многое…многое…многое другое, что мы тут просто не опишем, ибо это будет слишком сложно звучать. Но автоматики тут навешано нехило.
Наверное, пора заканчивать, а то наши статьи итак всегда запредельно большие (но, надеемся, интересные). Если есть вопросы по функционалу, то задавайте их в комментариях, с радостью ответим.
Для наших друзей-интеграторов также дадим немного статистической информации по настройкам данного проекта:
- Количество шаблонов задач – 42
- Количество процессов – 22
- Количество уникальных сценариев по всем процессам – 88
- Количество кнопок по всем процессам – 27
- Количество кастомных статусов – 5 (да-да, пять)
- Количество кастомных полей – 91
- Количество справочников – 31
- Количество проектов – 14
- Количество планировщиков – 17
И в конце, как и обещали, список всех внешних ссылок на другие наши статьи, информация из которых однозначно вам поможет в формировании понимания того, что может происходить при комплексном внедрении ПланФикса в компании.
- При внедрении CRM не надо садить коллектив сразу в кабину Боинга
- Что такое “Подготовка данных к переносу” в строке сметы на внедрение системы управления проектами
- Внедрение ПланФикса для производства одежды в период коронавируса
И набор ссылок на справку ПланФикса по функционалу, описанному в статье:
Спасибо за чтение и ваше время. Мы это ценим, правда.
P.S.
Отдельное спасибо хотелось бы сказать в сторону двух других интеграторов, которые тоже внесли свой вклад в этот проект. Во-первых, это Андрей Лежнин, который выступал в роли тех. поддержки на проекте в определённый период времени. И Степан Чельцов, который высказал очень добротные идеи по части функционала в процессе консультации.
Мы нисколько не скрываем факт того, что в работе иногда привлекаем силы других профессионалов, т.к. всё равно ответственность за результат (который является смесью технических и организационных способностей) лежит на нас. А несколько грамотных мнений со стороны всегда сделают результат более корректным. Уж мы это обеспечим.
Артём Колисниченко: Спасибо Сергею за подробный и познавательный рассказ о внедрении ПланФикса на швейном производстве. Напоследок хочу обратится к тем, кто только познаёт азы ПланФикса или раздумывает о его применении у себя на производстве: начните внедрять систему постепенно, небольшими порциями. И буквально за полгода плодотворной работы вы доберётесь до “кабины Боинга”. Это вполне реально. Рассказ Сергея тому подтверждение. И помните, вам всегда помогут партнёры-интеграторы. Кроме этого, на любые вопросы ответит и Служба поддержки ПланФикса.
Артём, большое спасибо за ценный пример глубокой кастомизации PlanFix’а при решении объемной бизнес-задачи!
Илья, давайте лучше скажем спасибо Сергею за его бесценный опыт внедрения ПланФикса)
🙂
Спасибо, Сергей!
Очень познавательно!
Сергей спасибо за статью. Вчера и сегодня на выставке (2-3 сентября 2020) много общались с потенциальными клиентами. Раза два или три вспоминал добрым Сергея Улаева (еще до выхода этой статьи здесь читал про этот проект другие статьи, в том числе в блоге компании Сергея) и говорил Клиентам что по производству есть очень мощная команда.
Всем с кем общался обещал выслать ссылки на видео и на блог. Обязательно теперь помимо общей ссылки на блог отправлю им отдельно ссылки на избранные статьи которые показывают всю мощь планфикса.
Ого. Спасибо, Илья!
Из неописанного здесь (ну вот муза так захотела в момент написания статьи), но точно интересного для производств:
– возможность подсчёта себестоимости продукции
– возможность расчета всего объёма закупки для плана на пошив (по каждой номенклатурной позиции в отдельности)
Как-нибудь сделаем видосики на эту тему.