Внутренние процессы компании
Разработка корпоративных информационных систем
Корпоративная информационная система связывает работу сотрудников: кто принимает заказ, кто отвечает за исполнение, какие данные нужны следующему участнику. GradientPrime разрабатывает внутренние системы под процессы компании, когда возможностей готового решения недостаточно.
Помогаем определить рабочие места, правила учёта и права доступа, выбрать границы первой версии и условия её внедрения. Результатом может стать собственная CRM, система учёта заказов или инструмент для совместной работы подразделений.
Когда стандартная система не покрывает процессы компании
Сначала полезно проверить, можно ли решить задачу настройкой уже используемой программы или готового продукта. Если необходимые поля, роли и переходы доступны, внедрение собственного ПО может оказаться избыточным. Разработка имеет смысл, когда существенные правила работы приходится постоянно обходить с помощью таблиц, переписки и повторного ввода.
Условный пример: компания собирает оборудование под заказ. Менеджер согласует комплектацию, снабжение проверяет наличие деталей, а производство планирует сборку. В CRM хранится сделка, но изменения её состава исполнители обсуждают в отдельных файлах. Для общей работы может понадобиться система, которая связывает заказ, его актуальную комплектацию и задания подразделениям.
При обследовании нужно выяснить, что именно не поддерживает текущая программа: связь записей, порядок изменений, права участников или обмен данными. Ответ поможет выбрать между настройкой, отдельным внутренним инструментом и созданием системы с более широким составом функций.
Сравнить объём изменений
Для каждого варианта важно оценить работу сотрудников, перенос данных, ограничения интеграций и дальнейшее сопровождение. Собственная система требует ответственных за правила работы и развитие требований со стороны компании.
Разработка ПО на заказРабочие места сотрудников, роли и связанные данные
Рабочее место определяет, какие записи сотрудник видит, какие действия выполняет и что передаёт дальше. Проектирование начинается с этих обязанностей и общего состава данных.
Менеджер: условия заказа
В условном примере менеджеру нужны заказчик, согласованная комплектация, история уточнений и готовность к передаче в работу. Определяем, какие сведения он вводит сам, а какие получает от коллег.
Отдельный вопрос — изменение заказа после начала сборки. Кто вправе его предложить, кто подтверждает возможность и как сохраняется предыдущая версия условий?
Исполнитель: задачи и ограничения
Снабжению и производству нужны задания, связанные с тем же заказом, актуальные требования и сведения о готовности предыдущего этапа. Для каждого подразделения согласуем доступные поля и переходы состояний.
Например, сотрудник отмечает готовность деталей, но не меняет коммерческие условия. До разработки уточняем, какие действия разрешены только ответственному и как работает замещение.
Руководитель: ход работы
Руководителю может требоваться сводка заказов, приоритетов и причин остановки. Показатели должны опираться на согласованные состояния и события, иначе подразделения будут по-разному понимать одну цифру.
Для обследования: что означает «готов к сборке», кто подтверждает это состояние и какие заказы должны попасть в список ожидающих комплектующих?
Автоматизация отчётностиСвязанные записи позволяют перейти от заказа к его составу, заданиям и документам. Для каждого вида данных определяем основную систему хранения, идентификатор и ответственного за исправления. Права описываем через конкретные действия: просмотр, создание, изменение и подтверждение; отдельно учитываем доступ по подразделениям.
Если рабочие места доступны через браузер, нужно также определить требования к интерфейсу и пользовательским сценариям. Здесь состав системы определяется совместной работой сотрудников и правилами учёта.
Веб-приложения для бизнесаСобственная CRM, учёт заказов и внутренние инструменты
Состав решения зависит от того, какой участок работы нужно объединить. Эти варианты можно рассматривать по отдельности; включать все возможности в первую версию необязательно.
CRM под правила продаж
Разработку CRM на заказ стоит рассмотреть, если отношения с клиентами, структура сделок или правила согласования существенно отличаются от возможностей готовых решений. В проекте определяют карточки клиентов, контакты, историю взаимодействия и переход к исполнению заказа.
В условном примере полезно связать несколько вариантов комплектации с одной сделкой и явно отметить выбранный. Перед разработкой проверяем, можно ли сделать это в текущей CRM без создания новой.
Система учёта заказов
Если основные сложности начинаются после продажи, можно сосредоточить систему на составе заказа, заданиях подразделений и контроле исполнения. CRM и бухгалтерская программа при этом могут сохранить свои задачи.
Для компании из примера обсуждаем связь заказа со сборкой и готовностью деталей, частичное выполнение и изменение состава. Требования должны показать, как сотрудник найдёт актуальное задание и зафиксирует результат.
Учёт и обработка заказовИнструмент для отдельного участка
Иногда достаточно рабочего инструмента для согласования спецификаций, ведения справочника или получения сводки по заказам. Его границы определяют по операции, которую сотрудники сейчас выполняют вне основных систем.
Например, можно обсуждать журнал изменений комплектации: кто предложил замену, кто подтвердил и какая версия передана в производство. До выбора решения нужно понять, где хранится исходный документ и как фиксируется решение.
Работа с документамиОбследование процессов и границы первой версии
Предлагаем разобрать один процесс от входа до проверяемого результата вместе с его участниками. Глубину обследования и состав материалов согласуем под проект; важно увидеть как обычный ход работы, так и исключения.
1
Разобрать текущую работу
На обезличенных примерах прослеживаем, откуда приходит заказ, какие сведения добавляет каждое подразделение и где принимаются решения. Фиксируем ручные переносы, ожидания и расхождения между регламентом и фактическими действиями.
2
Согласовать правила и данные
Описываем записи, обязательные поля, роли, переходы и исключения. В примере со сборкой нужно решить, что происходит при нехватке детали или изменении заказа: кто приостанавливает работу, кому передаёт вопрос и на каком основании её возобновляет.
3
Выделить завершённый участок
Первую версию можно ограничить одной группой заказов или подразделений, если выбранный путь остаётся рабочим. Для примера это может быть передача согласованного заказа в сборку с подтверждением готовности деталей. Зависимые данные, права и обработку ошибок учитывают сразу.
4
Определить проверку и переход
Для каждого сценария записываем ожидаемый результат и участника приёмки. Согласуем, какие операции перейдут в новую систему, какие пока останутся в прежних программах и кто отвечает за связь между ними в переходный период.
Результатом обследования может стать описание процесса, состава данных, прав и границ первой версии с критериями приёмки. Эти материалы помогают оценить объём разработки. На оценку также влияют качество прежних данных, сложность подключений и условия эксплуатации; неизвестные параметры нужно уточнить до планирования соответствующих работ.
Перенос данных и интеграции
Перенос накопленных записей и текущий обмен с другими программами требуют отдельных правил. Сначала определяем, какие данные нужны для начала работы: справочники, открытые заказы, документы и необходимая история. Старые записи можно оставить доступными в прежней системе, если этого достаточно для согласованного сценария.
До переноса сопоставляем поля и идентификаторы, разбираем дубли и неполные записи. Например, в условной компании один и тот же заказчик может быть записан под разными названиями, а позиции в таблицах — без общего кода. Правила объединения должен подтвердить ответственный сотрудник; неоднозначные записи требуют разбора.
Для обмена с CRM, бухгалтерской программой или складским учётом выясняем доступные интерфейсы, форматы и ограничения. Затем согласуем, где создаётся запись, какие изменения передаются и как быстро. В примере со сборкой важно определить источник сведений о деталях: устаревший остаток не должен выглядеть как подтверждение готовности к работе.
До рабочего перехода полезно предусмотреть пробную загрузку и сверку: количество заказов, их состав, состояния и связи с документами. Порядок повторной загрузки, остановки перехода и возврата к прежнему учёту согласуется заранее, включая судьбу записей, созданных во время проверки.
Интеграция системЧто выяснить до подключения
- Какая система хранит актуальную запись и кто вправе её исправлять.
- Как связать номера заказов, клиентов и документов в разных источниках.
- Что видит сотрудник при задержке обмена и кто разбирает ошибку.
- Как повторить передачу после сбоя без создания дубля.
- Кто подтверждает корректность переноса и готовность к рабочему переходу.
Приёмка, обучение пользователей и развитие
Готовность системы проверяют по согласованным операциям сотрудников и достоверности результата. До внедрения нужно также определить порядок обучения, помощи пользователям и внесения дальнейших изменений.
Проверить работу каждой роли
В приёмке участвуют представители подразделений. Они проходят обычные операции и согласованные исключения: изменение заказа, нехватку данных, возврат на уточнение и попытку действия без нужных прав.
В условном примере менеджер меняет комплектацию, снабжение видит актуальную потребность, а производство получает подтверждённое задание. Отдельно проверяют, что прежняя версия остаётся в истории и не используется как действующая.
Подготовить пользователей
Обучение можно построить вокруг действий конкретной роли: найти задание, внести результат, вернуть вопрос на уточнение. Формат занятий, инструкции и состав передаваемых материалов согласуются в проекте.
Перед запуском выясняем, к кому сотрудник обращается при неверных данных или недоступном действии. Ответственные за выдачу прав, справочники и работу системы должны быть определены заранее.
Планировать следующие изменения
После начала работы полезно собирать замечания по конкретным операциям: где не хватает сведений, когда приходится возвращаться к таблице и какие исключения не учли. Это помогает отличить ошибку от нового требования.
Порядок сопровождения, размещение, передача исходного кода и права на результат согласуются отдельно. Новые подразделения, отчёты и подключения добавляют по приоритетам с повторной проверкой затронутых сценариев.
Частые вопросы
Вопросы перед разработкой внутренней системы
Обсудим внутреннюю систему для вашей компании
Расскажите, какие подразделения участвуют в работе, где хранятся данные и какие операции приходится выполнять вручную. Для начала полезны описание одного процесса и обезличенные примеры записей. Поможем определить границы первой версии и вопросы для оценки проекта.
Обсудить задачу