Жила-была, да и живет, одна производственная компания. Производила, да и производит, индустриальные смолы, да и продает их. Объемы - порядка 10 тысяч тонн в месяц. А для удобства клиентов, нанимает для перевозки транспорт сторонний. И рулил, да и рулит этим делом, отдел логистики.

Только вот незадача: вел он все это дело в ёкселе. Да не только он, а еще продажники и прочие финансисты. Мы с вами, как автоматизаторы, знаем: в ёкселе можно сделать все - но криво. А еще он ни разу не многопользовательский, потому ежечасные крики "где актуальные данные", "кто заблочил эксель", "ексель сломался", "мне только посмотреть" были слышны отчетливо и даже без телефонной связи.

Данные в этом ёкселе были структурированы удобно: в виде шахматки, где столбцы - это дни в месяце, а строки - клиенты да виды готовой продукции. В самой шашечке - объем в тоннах, а цвет шашечки - состояние: запланировано, отгружено, задержано и т.д. Словом, лепота - но только для "посмотреть". А вот для "ввести данные" в режиме реального времени, для "создать отчет в разных разрезах", для "создать документы в четной системе", для "где эта чертова машина" - совсем не айс.

Закупать какую-то систему - не стоило, т.к. процесс сильно специфический. переходить на всякие ERP - тоже, так как, как говорит мой руководитель, "культура заказчика крайне низкая". Выход один - что-то доделывать в рамках существующей системы компании, 1С:Бухгалтерия Корп 8.3. Из ресурсов тебе - вон, у нас есть программист, который облизывает бухгалтерию в "критические дни" - закрытие месяца, с ним и работай.

Так и выглядела исходная постановка задачи.

И сел я думать, и придумал следующее. 1. Общий вид модуля - сохранить. То есть да, шахматка, но - с настраиваемыми фильтрами по датам и т.д. 2. Строки шахматки - те, которые клиенты и вид продукции - это заявка покупателя, которую получают от него в виде таблички вида "10 числа хочу 100 тонн, а 12го - еще двести". Она и раскладывалась в ширину, пока в фильтр по дате влезает. 3. Вся обработка шахматки - автоматическая. То есть, подали заявку транспортнику - клетка окрасилась. Получили ответ от него - еще окрасилась. Отгрузили - позеленела. И так далее. 4. Обвесить сервисом отправки заявок (заказ машин) в виде как он есть - эксельчики установленной договорами формы (слава богу, что они были). 5. Соорудить сервис приема ответом на эти заявки - получение данных машин-водителей как сигнал "точно приеду" - ну и красим шахматку. 6. Соорудить дополнительные АРМы - Охрана, Весовщик, Диспетчер, Лаборатория и т.д. - для обслуживания полного цикла от "запланировали отгрузки" до "исполнили отгрузки и создали УПД" 7. и еще миллион плюшек - уведомление водителей по смс, информационный экран на стоянке с очередностью погрузки, цифровизация паспорта качества на партии - с подписанием ЭЦП, и многое другое.

Результаты: - Деятельность логистов свелась к тому, к чему должна: они искали перевозчика под конкретную отгрузку, и дальше все система делала сама. Они видели статус ответа на заявки, если ответа нет - то тормошили транспортника. - Деятельность по исполнению отгрузок ушла в соответствующие подразделения, а логисты и руководство видели лишь зеленеющую таблицу. - Остальные подразделения получили онлайн-контроль за процессом, без вышеупомянутых стонов и вопросов, а все ли данные внесены. - Стало возможно планировать отгрузки с учетом производственного парка - точки налива и их производительность. Это ликвидировало транспортный коллапс на территории - когда стоит куча машин и непонятно, кого и когда будут грузить

Отдельная профессиональная гордость: в ходе внедрения на двух весьма удаленных друг от друга производственных площадках с графиком 24/7 у меня не было ни одной бессонной ночи, да и звонков на тему "все пропало, что делать" - было немного.

Некоторые скрины системы.

1. Та самая шахматка, как ядро системы 2. Отправка заявок на перевозку, на каждый машино-рейс 3. Рабочее место оператора налива 4. Планирование исполнения отгрузок (по точкам налива и времени) 5. Рабочее место для Охраны

Общий срок на разработку и внедрение - 10 месяцев.