Артур Карданов

Почему «Контур Логики»: сначала границы, потом правила

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

Название появилось из самого подхода к разработке. Работа начинается с аудита: сначала нужно обозначить контур автоматизации — границы задачи. Что будем менять? Какие подразделения и операции затронем? Что уже работает и должно остаться за пределами проекта?

После этого начинается работа с логикой: как устроен процесс, кто принимает решения, какие правила должна выполнять система и что происходит в нестандартных ситуациях.

Так и получилось: «Контур Логики».

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

Контур: что именно мы собираемся автоматизировать

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

Если начать разработку до того, как задача станет конкретной, границы будут постоянно сдвигаться. К учёту операций добавится склад, затем закупки, потом расчёт зарплаты — и проект окажется значительно шире исходной потребности.

Поэтому на старте я выясняю:

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

Не менее важен последний вопрос о границах: что мы сейчас не автоматизируем? Это помогает сохранить управляемый объём работ и сосредоточиться на задаче, ради которой начат проект.

Необязательно менять всё, чтобы решить одну проблему

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

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

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

Какие задачи могут входить в такие проекты, я описываю отдельно в разделах автоматизации производства и MES и складских систем WMS.

Логика: как система должна вести себя в реальной работе

Когда границы определены, недостаточно составить список экранов и кнопок. Нужно разобраться в правилах самого процесса.

Например, операция выполнена только частично. Можно ли передать результат дальше? Кто подтверждает количество? Что происходит с остатком? Как учитывается брак? Можно ли исправить ошибку после закрытия смены и кто увидит это изменение?

На складе возникают свои вопросы. Что делать, если товар физически находится не в той ячейке? Допустим ли частичный отбор? Кто разрешает замену партии? Как поступить с возвратом без привычного комплекта документов?

Именно ответы на такие вопросы превращают общую идею автоматизации в рабочую модель. Если оставить их «на потом», сотрудникам придётся самостоятельно закрывать пробелы: вести параллельные таблицы, переписываться в мессенджерах и договариваться устно.

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

Зачем аудит нужен до выбора решения

Для меня аудит — способ понять задачу до того, как обсуждать конкретные технологии и объём разработки. Он помогает отделить проблему процесса от проблемы инструмента.

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

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

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

Индивидуальное ПО должно оставаться понятным заказчику

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

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

«Контур Логики» для меня — короткое объяснение того, с чего начинается работа: определить границы задачи и разобраться в правилах, прежде чем писать программу.

Обсудим ваш контур автоматизации. Опишите, где сейчас возникают потери времени, ошибки или непрозрачность, какие программы уже работают и какого изменения вы ждёте. Связаться со мной.

Если у предприятия уже был сложный опыт, полезно отдельно разобрать, что проверить после неудачного внедрения ПО. При выборе исполнителя пригодится статья о проверке ИП и ООО при заказе разработки.