от

Внедрение системы управления проектами (производством) на базе Планфикс (Часть 1)

Магнитогорск

— — —
Если вы попали сюда напрямую, минуя общее описание всей этой истории, и не понимаете, о чём это вообще, то советуем вам начать чтение с самого начала.

А далее будет продолжение истории
— — —

 

01.08.18 – 22.08.18

Урал. Город Магнитогорск.

Я точно помню, что приехал к клиенту 01.08.18. И сразу взялся за несколько задач. Среди которых было и внедрение. Я потихоньку разбирался в бизнес-процессах компании, чтобы понять – а с чего вообще начать внедрение? С какой стороны подойти? Начать с производства? А может отдела продаж (которые на тот момент работали совсем в другой CRM системе под нашим же контролем)? Или бухгалтерии?

Помню лишь, что за 3 недели уже наработался результат, который сейчас разом опишу. А далее будет как обычно – по важным дням, но так же интересно 😊.

«С чего начать внедрение?»

Очень важный вопрос. ОЧЕНЬ важный вопрос. Потому что компания не стоит на месте – она генерирует результат своего вида деятельности. Коллектив в компании, соответственно, каждый день делают свою работу уже как-то! И тут приходит «кто-то» со стороны и говорит «скоро будете работать по-другому».

Не буду тут писать об эффекте охреневания от скорого непонятного будущего, который наверняка охватывал коллектив. Но аллегория тут такая – нам нужно было вносить изменения, НЕ останавливая текущую работу всего персонала. А если что пойдёт не так, то надо максимально оперативно убирать сложности в работе:

Внедрение системы управления проектами (производством) на базе Планфикс (Часть 1)

Вот там, похоже, как раз я :).

В общем, к вопросу «с какого отдела начать» я подошёл довольно серьёзно. И главным критерием выбора был ответ на вопрос «какой отдел обновляет информацию медленнее всего»?

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

Это как если бы вы 10 раз обновили ленту в Instagram, но в ней бы ничего не обновилось.  Вы старались, делали это быстро. А новой информации – ноль.

И вот мне надо было определить тот отдел, который обновляет информацию о результате своего труда максимально медленно. Чтобы с него и начать. Это тот вагон, который движется отдельно от всего остального поезда…по своей дороге и очень медленно.

Бухгалтерия – пришёл мне ответ одним жарким вечером!

Вообще, думаю, в любой компании это именно этот отдел и с него надо начинать внедрение. Ну серьёзно – производство может каждый день делать новые детали чего-либо, причём сотнями штук. Но вот договорА – это штучная вещь. Сотни штук за день не сделаешь. Там за год бы столько заключить.

В общем, с отделом определились. Дальше нужно было понять, где именно и в каком виде хранить результат работы бухгалтерии. Причём в систему заводилась НЕ вся работа бухгалтерии, а лишь самая важная часть, которая может в процессе работы быть необходима другим отделам компании – отделу проектирования, продаж или уже производству. В основном – это самая основная информация по договорам и приложениям к ним.

Как это хранить в системе – решать мне. Потому что это Планфикс, «детка» 😊. Я вот за что обожаю эту систему – так это за то, что она как «пластилин», из неё можно «слепить» что угодно и пользоваться этим в работе. И там нет единственно верного решения на тему «где и как хранить информацию по договорам». Нет.

Там есть базовый функционал, позволяющий где-то что-то как-то хранить. А как это будет реализовано – решать вам. Это как Lego для бизнес-процессов компании. Я не могу подобрать другую аналогию. У них это прекрасно описано в их идеологии работы.
Внедрение системы управления проектами (производством) на базе Планфикс (Часть 1)

Поэтому я начал с архитектуры проекта. Это некое прототипирование будущей системы. Как и в любой теме строительства чего-либо, первый этап – самый важный. Как здание спроектируешь – так и стоять будет. Никто не «вписывается» в масштабную стройку без проекта.

А я в тот момент для компании не «одноэтажный дом» строил. Я строил «бизнес-центр», в котором будут работать и взаимодействовать между собой разные отделы. Без проектирования тут не обойтись.

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

Начну с того, что информация в системе будет храниться в сущности под названием «Справочник» (за ссылками будут скрываться описания этих сущностей на самом сайте системы в их справке). Справочник будет называться «Договора» (капитан очевидность проснулся, его позвали 😊 ). Но внутри этого справочника вся информация будет храниться в 2х разных «папочках»:

  • Основные договора
  • Приложения

Каждая папка будет иметь свой набор полей.

справочник в планфиксе

Почему нельзя в одной папке всё держать?
Потому что на бумаге это  разные документы с разной информацией. В одном документе есть информация про НДС и доставку, в другом нет. И наоборот. И чисто технически можно придумать, как хранить это в одной структуре, но будет неудобно и идеологически неправильно

 

Как их связывать между собой?
А для этого в договорах есть поле, где указываются приложения именно к этому договору. Клик – и можно сразу уйти в нужное приложение с его полями. Получилось довольно удобно:

связка договора и приложения

Для этих справочников мы настроили уровни доступа для нужных отделов компании.

И следом настроили первые отчёты, которыми уже могут пользоваться сотрудники. Могут…смогут…смогли бы…если бы пользовались бы…в общем до реальной практики использования самими сотрудниками ещё далеко (срок измеряется в месяцах 😊). Но мы же «архитекторы» системы, поэтому мы ставим себя на место рядовых сотрудников компании и задаём сами себе вопрос «какие отчёты мне были бы полезны в работе?».

Пока в голову приходит ответ «да основные, просто общая информация по договорам и приложениям».

Ну ладно – сделали:

отчеты в планфиксе

В общем, у нас есть отчет по договорам + отдельный отчёт по всем приложениям ко всем договорам.

По договорам это выглядит так (все картинки кликабельны для бОльшего размера):

информация по договорам

 

По приложениям к договорам так:

приложения к договорам

А ещё есть отчёт по контактам к компаниям-заказчикам:

отчет по контактам

 

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

И мы рисуем. В самом начале она состояла из 5 элементов (сущностей, блоков, хз как назвать). Сущность «контрагент» пришлось разбить на 2 (физ. лицо и юр. лицо), т.к. у них тоже есть разный набор полей для работы:

первая схема архитектуры

Видите стрелочки? Они очень важны. Вот прямо ОЧЕНЬ. Именно они в будущем и могут спасти вас от ситуации «сделал тут – сломал там», потому что по этим стрелочкам сразу видны все взаимосвязи того или иного поля сущности.

Чуть позднее в эту схему добавился справочник «Заявки» – это PDF документы, которые «выходят» из отдела проектирования. У них тоже были свои связи со справочниками документов.

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

Вторая версия схемы выглядела так:

архитектура системы версия 2

Хотя я тут подумал…не могу я не грузить вас техническими деталями, иначе тут особо читать нечего будет. Нам же как раз надо показать всю силу и мощь такого инструмента как «Система управления проектами Planfix». Но если вы будете чувствовать, что в предложениях вы понимаете по большей части лишь предлоги, то можете просто смотреть лишь на картинки, потому что они итак будут отображать всё самое необходимое в нашей работе по внедрению системы.

А я поведу свой рассказ дальше. Итак, на самом деле предложение «мы добавили сущность “элемент изделия”» имеет огромное значение, т.к. это является самым главным элементом системы, чтобы всё производство могло фиксировать результаты своего труда.

А фиксацию результатов мы сделали через использование т.н. «аналитик» Планфикса. Это очень интересная возможность системы и лучше почитать о ней у них в справке по ссылке выше.

Наличие аналитик позволяет делать крутые отчёты о процессе производства (лучше кликнуть и развернуть картинку в новом окне):

отчеты производства

Пока что представленное выше – это тестовые данные. И ничто не может лучше показать все изъяны системы, как настоящая практика жизни компании. Но мы не можем сразу на следующий день подключить к системе всё производство, чтобы они заносили информацию. Он ж ох…ют. Да и я более чем уверен, что мы на 10 раз всё переделаем ещё в процессе работы.

Поэтому для постепенного внедрения системы (а точнее это ещё даже и не внедрение, а создание фундамента под внедрение) решено, что все данные в первое время будет заводить тот, кто внедряет (Я). А люди будут передавать мне рабочую информацию наиболее удобным для них способом – на бумаге.

Не потому что я так решил, что самый удобный для них способ – это бумага. Нет, им реально было так удобнее. Ведь сейчас у них, на самом деле, есть своя собственная «система учета производства». Только это больше похоже на древние манускрипты, язык которых знает лишь тот, кто эти манускрипты пишет.

Внедрение системы управления проектами (производством) на базе Планфикс (Часть 1)

Думаете, я шучу? А как вы можете описать тетрадку, где данные фиксируются так (примерно на память, но больше важна сама идея):

  • Если нарисован квадратик – значит изделие на этапе резки
  • Если нарисован треугольник – то его уже собрали
  • Если цифра обведена карандашом – значит мы ожидаем поступление этих деталей, но их ещё нет.
  • А вот когда карандаш мы обводим ручкой, значит детали уже пришли
  • И т.д.

Вы представляете, что случится, если вдруг из рабочего процесса выпадет тот, кто ведёт эти записи (заболеет, уволится)? Всё – у всего производства уйдут целые ДНИ  только на самостоятельное понимание того, что сделано и что надо делать дальше.

А думаете, в других местах по другому? Да хренос-два. Система “рабочая тетрадка в клетку” в наше время успешно процветает во многих компаниях. То, что здесь руководство понимало этот факт и стремилось исправить его – прекрасно.

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

  • Что было сделано вчера
  • Что планируется сделать сегодня / завтра
  • Кто занёс результаты
  • Сколько осталось сделать
  • И т.д.

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

листки для заполнения данных

А я потом буду лично эту информацию заносить в систему и понимать, насколько это вообще удобно – работать в системе при текущей архитектуре. И когда я пойму, что это реально удобно и сделать лучше уже нельзя – то подключу людей к работе в системе.

Часть № 2 можно прочитать по этой ссылке

Если вы хотите узнать о нас больше и обсудить варианты возможного сотрудничества, то вам на страницу “О нас. Кто мы. На что способны”.

Добавьте комментарий

Комментарии

  1. Для описанных задач Планфикс далеко не лучшая система. И, хотя он мне идеологически нравится, но больше подходит как задачник, а не система для управления процессами. Решить-то там это можно, но стоимость всего этого из-за отсутствия простоты и необходимости последующей поддержки при изменении процессов… игра не стоит свеч

    По описанным задачам и вашему подходу к их решению чувствуется, что у вас не хватает опыта серьезных внедрений.

  2. Любое мнение ценно. Спасибо за отзыв

  3. Что за софт используете для построения архитектуры?

    И не совсем понял, как у вас связь договоров и приложений построена?
    В договоре есть поле с приложениями, но ведь если добавить приложение , то обратная связь сразу не прославится, фиксировали ручками?

  4. да, в договоре есть связь на приложения. В приложения есть связь (полем) на договора. Просто надо в голове помнить, что если добавили приложение, то надо прописать его и в договоре. Ну..или не помнить, ибо на это дело у нужного человека есть чек-бокс в нужной задаче. Перед закрытием задачи этот момент всё равно “вылезет” и надо будет его исправлять.

    Софт – Draw.io (бесплатный)