Артём Колисниченко: Мы продолжаем путешествовать по компаниям и изучать, как предприниматели из разных сфер применяют в работе ПланФикс. На этот раз у нас получилось понаблюдать за тем, как система работает на производственном предприятии.

Мы попали в компанию «Камский Берег-Станкострой» из Ижевска. Экскурсию провел Дмитрий Бычков. Он является основателем и идейным вдохновителем использования ПланФикса на производстве.

Дмитрий не только провел экскурсию, но и подготовил соответствующую конфигурацию. Передаю слово Дмитрию для презентации конфигурации, а в конце добавлю запись экскурсии по ПланФиксу компании «Камский Берег-Станкострой».

Дмитрий Бычков: Представляю сообществу конфигурацию, созданную по аналогии с рабочей системой управления предприятием используемой в компании ООО «Камский Берег-Станкострой», г. Ижевск.

Предприятие существует порядка 20 лет и занимается производством оборудования. В основном, в номенклатуре производства деревообрабатывающее оборудование и заточные станки.  Часть продукции (например, небольшие заточные станки) делается «на склад», но основная продукция — деревообрабатывающее оборудование — делается под заказ, и цикл производства часто длится от 2 до 4 месяцев и больше.

Компания небольшая, но задачи управления, в общем, типичны и не зависят от масштаба: обработка запросов, отслеживание заказов в производстве, планирование закупок, счета, контрагенты, зарплата, поддержка клиентов и т.д. Всего в компании около 70 сотрудников из них 14 человек работают в аккаунте ПланФикса.

Я уже коротко описывал, как ПланФикс появился в нашей компании.

Могу сказать, суммируя накопленный опыт: система управления предприятием на основе ПланФикса в полной мере оправдала возлагавшиеся на неё надежды и является весьма функциональным решением с большим запасом, закрывающим потребности компании.

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

Предлагаемая сообществу конфигурация сделана «по аналогии» с рабочей системой. Я постарался убрать исторически сложившиеся необязательные фрагменты и сделать более универсальный вариант. Далее опишу основные модули системы и добавлю немного комментариев.

Процесс «Сделки» (CRM)

Это рабочий инструмент отдела продаж. Основная механика построена по принципу «на чьей стороне мяч?». Данный блок является развитой записной книжкой для продажников и просто облегчает им работу. При этом модуль не является инструментом для «понукания» менеджеров или сравнения их по «успешности».

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

Статус «Ждем оплаты», который можно бы было здесь ожидать,  отсутствует, так как при этом «Сделка» уже превращается в «Заказ» в статусе «Предварительно». Если клиенту выставлен счет — следовательно, его запрос просчитан, составлена спецификация, согласованы с производством сроки, с клиентом согласован договор. То есть проведена существенная работа и это уже «без пяти минут» заказ:

Процесс «Заказы»

Отслеживается жизненный цикл заказа (в нашем случае – заказа на изготовление станка). Рабочий график, по которому ориентируются офис и производство.

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

Как правило, работа над Заказом ведется долго — от нескольких месяцев до года и больше. Продукция (оборудование) эксплуатируется у клиента значительное время, так что данные из «Заказа» становятся чем-то вроде «досье», к которому может возникнуть необходимость обратиться через несколько лет после отгрузки

Процесс «Закупки»

Предназначен для отслеживания и планирования закупок ТМЦ.

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

Когда задача переводится в статус «Новая Закупка», она принимается к исполнению снабженцами и переводится в статус «В работе, не заказано».

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

Аналогично происходит при поступлении заказанных позиций на склад. В той же аналитике отмечаются чек-боксами поступившие позиции, и задача переходит в статус «Выполненная».

С процессом «Закупки» через общий справочник «Товары» связан процесс «Списание».

На основе данных из «Закупки» и «Списание» строится отчет «Движение товаров». По данному отчету можно отследить:

• какие товары запрошены производством,
• какие уже заказаны у поставщика,
• какие поступили на склад,
• что есть в остатках на складе,
• сколько и чего еще нужно заказать.

Процесс «Счета»

Отслеживаются оплата счетов и взаиморасчеты с поставщиками.

Счет от поставщика регистрируется в системе и обязательно привязывается к «Закупке» в качестве подзадачи. Таким образом, по каждой «Закупке» можно узнать: какие есть счета, как обстоят дела с их оплатой и поступлением товаров по ним:

Процесс «Зарплата»

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

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

Для того, чтобы в таблице (аналитике) были видны накопленные остатки по предыдущему периоду используется идеология последовательного создания задач (одна за другой) с передачей данных по итогам по каждой строке через вебхук:

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

Для полноты картины в конфигурации предусмотрены рабочие группы и соответствующие им рабочие пространства, характерные для производственной компании:

Как запустить конфигурацию

Коротко о том, что потребуется для превращения конфигурации непосредственно в рабочую систему:

• Настройка обработки входящих сообщений и запросов.
• Настройка рабочих групп, должностей, рабочих пространств, прав доступа сотрудников.
• Учёт специфики продукции вашей компании.
• Загрузка справочников.
• Интеграция шаблонов документов.
• Настройка отчетов (в конфигурацию включен минимум).

Я готов предоставить всем желающим ссылку для скачивания данной конфигурации полностью бесплатно при учете следующих обстоятельств:

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

Также по запросу могу предоставить пользовательский доступ к аккаунту с установленной конфигурацией для ознакомления.

---

Артём Колисниченко: В завершение хочу поблагодарить Дмитрия за рассказ о конфигурации и в целом за проведенную экскурсию. Спасибо вам большое!

Как и обещал, добавляю запись экскурсии:

---

Не забывайте о наших социальных сетях: ВКонтакте, Telegram и ВК Видео. Там появляются новости о доработках и новинках. Подпишитесь, чтобы ничего не пропустить.