Разработка корпоративного приложения: этапы, сроки и стоимость
Гайд для того, кто готовит решение и должен его обосновать. Главное здесь — постановка задачи: она определяет и смету, и то, будут ли люди пользоваться результатом.
Коротко
Коротко
- Корпоративное приложение закрывает один процесс, а не «всё сразу». Задача, сформулированная как «нам нужна система», не оценивается и не внедряется.
- Постановка задачи — самая дешёвая и самая влиятельная часть проекта. Экономия на ней возвращается переделками.
- Способов закрыть задачу пять, и выбор определяется не бюджетом, а тем, кто будет менять приложение через полгода.
- Роли и права решаются до старта: добавить права, зависящие от данных, в готовое приложение означает переделку.
- Бюджет обосновывается четырьмя величинами, и все четыре замеряются до начала проекта.
Что называют корпоративным приложением
Корпоративное приложение — внутренняя система, в которой работают сотрудники или контрагенты компании. У неё есть учётные записи, роли, данные и правила, по которым эти данные меняются. Внешне она может выглядеть как страница сайта, а по устройству это приложение.
Отличие от продукта, который компания продаёт, лежит не в технологиях. У корпоративного приложения известный круг пользователей, измеримая польза внутри компании и главный риск, связанный не с конкуренцией, а с тем, что система не приживётся.
Отличие от учётной системы важнее. 1С и подобные ей продукты ведут учёт — это ядро, в котором лежат обязательства, деньги и остатки. Корпоративное приложение обычно живёт вокруг ядра и закрывает то, чего в нём нет и не должно быть. Кабинет контрагента, маршрут согласования, заявки в службы, реестр с удобным поиском.
Практический признак, отделяющий задачу для приложения от задачи для доработки учётной системы. Если операция меняет учётные данные — ей место в ядре. Если она их только читает и добавляет вокруг них процесс — это приложение.
Отличие от продукта, который компания продаёт, лежит не в технологиях. У корпоративного приложения известный круг пользователей, измеримая польза внутри компании и главный риск, связанный не с конкуренцией, а с тем, что система не приживётся.
Отличие от учётной системы важнее. 1С и подобные ей продукты ведут учёт — это ядро, в котором лежат обязательства, деньги и остатки. Корпоративное приложение обычно живёт вокруг ядра и закрывает то, чего в нём нет и не должно быть. Кабинет контрагента, маршрут согласования, заявки в службы, реестр с удобным поиском.
Практический признак, отделяющий задачу для приложения от задачи для доработки учётной системы. Если операция меняет учётные данные — ей место в ядре. Если она их только читает и добавляет вокруг них процесс — это приложение.
Пять типовых внутренних систем
Почти весь спрос на корпоративные приложения укладывается в пять типов. Знать их полезно, потому что типовая задача решается заметно быстрее и дешевле нетиповой.
Если ваша задача не попадает ни в один тип, это повод остановиться и переформулировать её. Чаще всего оказывается, что задача составная — в ней два или три типа сразу, и разумно брать их по одному.
Тип | Что закрывает | Кто пользуется | Что обычно становится сложным |
Личный кабинет | Контрагент видит свои данные и оформляет обращения сам | Клиенты, дилеры, поставщики, партнёры | Данные из учётной системы и разграничение доступа |
Заявочный сервис | Заявка проходит путь от создания до исполнения | Сотрудники и службы внутри компании | Маршрут с ветвлением и расчёт срока |
Маршрут согласования | Документ или решение проходит согласующих | Юристы, финансы, руководители | Пороги, замещение, версии документа |
Реестр или справочник | Учёт объектов, договоров, оборудования | Профильные подразделения | Права на просмотр и история изменений |
Внутренний портал | Единая точка входа сотрудника | Все сотрудники | Приживаемость и связь с остальными системами |
Если ваша задача не попадает ни в один тип, это повод остановиться и переформулировать её. Чаще всего оказывается, что задача составная — в ней два или три типа сразу, и разумно брать их по одному.
Признаки, что задача созрела до своего приложения
Не каждая потребность требует приложения. Пять признаков, при которых своё решение оправдано; двух-трёх достаточно, чтобы начинать разговор.
Обратный признак, который стоит проверить честно. Если процесс не описан и никто в компании не может его изложить целиком, приложение зафиксирует беспорядок и сделает его быстрее. Такую задачу начинают не с разработки.
Если процесс ещё не описан, начинать стоит не с приложения: как выбрать первый процесс и чем его закрыть.
- Операция повторяется часто. Ежедневно или еженедельно, а не раз в квартал.
- В процессе больше двух участников. Там, где работает один человек, таблица обычно дешевле приложения.
- У ошибки есть цена. В деньгах, в срыве срока или в проверке. Если цены нет, эффект не докажешь.
- Данные уже есть в системах. Приложение вокруг существующих данных даёт результат быстро; приложение, для которого данные надо сначала собрать, — это два проекта.
- Готовое решение не подошло. Вы смотрели готовые продукты, и на вашем процессе появились оговорки, которые они не закрывают.
Обратный признак, который стоит проверить честно. Если процесс не описан и никто в компании не может его изложить целиком, приложение зафиксирует беспорядок и сделает его быстрее. Такую задачу начинают не с разработки.
Если процесс ещё не описан, начинать стоит не с приложения: как выбрать первый процесс и чем его закрыть.
Пять способов закрыть задачу
Способы отличаются не столько ценой, сколько тем, что вы получаете в собственность и кто сможет менять приложение потом.
Первый способ выглядит самым естественным и чаще других оказывается ошибкой. Учётное ядро усложняется каждой доработкой, обновления становятся дороже, а процессная логика в нём и не должна жить.
Второй способ выигрывает, когда процесс типовой. Проверяется быстро — опишите свой процесс словами вендора; если получается без оговорок вида «а у нас ещё», берите готовое.
Способ | Срок | Что получаете | Чем платите |
Доработка учётной системы | Недели | Функция внутри 1С или аналога | Усложнением ядра, зависимостью от подрядчика по 1С |
Готовый продукт | Дни на настройку | Логику вендора и его методологию | Подстройкой процесса, платой за пользователей |
Платформа своими руками | Недели | Приложение в своей логике | Временем и квалификацией сотрудника |
Сборка ассистентом на платформе | Дни и недели | То же приложение, собранное по описанию | Потолком возможностей платформы |
Заказная разработка | Месяцы | Систему точно под задачу | Сроком, сметой и релизным циклом на изменения |
Первый способ выглядит самым естественным и чаще других оказывается ошибкой. Учётное ядро усложняется каждой доработкой, обновления становятся дороже, а процессная логика в нём и не должна жить.
Второй способ выигрывает, когда процесс типовой. Проверяется быстро — опишите свой процесс словами вендора; если получается без оговорок вида «а у нас ещё», берите готовое.
ПЯТЫЙ СПОСОБ
Приложение собирается по описанию задачи
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Вы описываете процесс словами или загружаете ЧТЗ. Ассистент переводит описание на объектный язык платформы — сущности, поля, роли, экраны, маршруты — и собирает приложение из компонентов, которые в платформе уже есть и уже работают. Правки вносятся в чате.
От заказной разработки это отличается устройством цикла. Там между потребностью и работающей системой стоит очередь и релиз на каждое изменение. Здесь очереди нет, и это меняет главное для внутренних задач — их можно закрывать по одной, не собирая проект на весь год.
Приложение собирается по описанию задачи
Nolan — ИИ-ассистент, который собирает приложение на low-code платформе. Он не заменяет платформу, а работает поверх неё.
Вы описываете процесс словами или загружаете ЧТЗ. Ассистент переводит описание на объектный язык платформы — сущности, поля, роли, экраны, маршруты — и собирает приложение из компонентов, которые в платформе уже есть и уже работают. Правки вносятся в чате.
От заказной разработки это отличается устройством цикла. Там между потребностью и работающей системой стоит очередь и релиз на каждое изменение. Здесь очереди нет, и это меняет главное для внутренних задач — их можно закрывать по одной, не собирая проект на весь год.
- личные кабинеты, заявки, согласования, реестры и внутренние порталы
- правки в чате без нового релиза
- заявленный эффект — в 10–50 раз меньше трудозатрат на типовое решение
Как поставить задачу: от процесса к требованиям
Самая влиятельная часть проекта и единственная, которую нельзя делегировать. Работает такой порядок.
Шаг первый — описать процесс как он идёт сейчас. Не как должен, а как происходит. С обходными путями, ручными сверками и случаями, которые «мы решаем в чате». Именно эта часть определяет половину объёма работ, и именно её обычно пропускают, потому что она неприятная.
Шаг второй — назвать участников и их роли. Кто инициирует, кто согласует, кто исполняет, кто контролирует. Отдельно — кто должен видеть всё, чтобы разбирать спорные случаи.
Шаг третий — выписать данные. Какие объекты живут в процессе, как они связаны и где лежат сейчас. Удобно записывать связями по одной строке — у подразделения есть лимит и руководитель, за каждым сотрудником закреплено подразделение, у заявки есть автор и позиции. Такой список сразу показывает, каких данных в компании ещё нет.
Шаг четвёртый — описать маршрут, включая отказ. Отказ, возврат на доработку, отмену и повторную отправку пропускают чаще всего, а случаются они с первого дня работы.
Шаг пятый — сформулировать, что считается результатом. Одна метрика и её текущее значение. Без текущего значения сравнивать будет не с чем.
Проверка качества постановки занимает десять минут. Прочитайте описание человеку, который процессом не занимается. Каждое место, где приходится добавлять «ну, там ещё бывает» — пропущенная ветвь, и она всплывёт в проекте.
Шаг первый — описать процесс как он идёт сейчас. Не как должен, а как происходит. С обходными путями, ручными сверками и случаями, которые «мы решаем в чате». Именно эта часть определяет половину объёма работ, и именно её обычно пропускают, потому что она неприятная.
Шаг второй — назвать участников и их роли. Кто инициирует, кто согласует, кто исполняет, кто контролирует. Отдельно — кто должен видеть всё, чтобы разбирать спорные случаи.
Шаг третий — выписать данные. Какие объекты живут в процессе, как они связаны и где лежат сейчас. Удобно записывать связями по одной строке — у подразделения есть лимит и руководитель, за каждым сотрудником закреплено подразделение, у заявки есть автор и позиции. Такой список сразу показывает, каких данных в компании ещё нет.
Шаг четвёртый — описать маршрут, включая отказ. Отказ, возврат на доработку, отмену и повторную отправку пропускают чаще всего, а случаются они с первого дня работы.
Шаг пятый — сформулировать, что считается результатом. Одна метрика и её текущее значение. Без текущего значения сравнивать будет не с чем.
Проверка качества постановки занимает десять минут. Прочитайте описание человеку, который процессом не занимается. Каждое место, где приходится добавлять «ну, там ещё бывает» — пропущенная ветвь, и она всплывёт в проекте.
Функциональные требования: что описать обязательно
Функциональные требования отвечают на вопрос, что система делает. Для корпоративного приложения обязателен минимум из шести пунктов — без любого из них проект придётся переделывать целиком.
Нефункциональные требования для внутреннего приложения обычно скромны, и это хорошая новость. Одновременных пользователей десятки, и запас по нагрузке в требованиях чаще всего лишний расход.
- Роли и видимость данных. Не список ролей, а что каждая видит и меняет. Отдельно отметьте права, зависящие от данных — свой филиал, свои контрагенты, суммы до порога.
- Статусы и переходы. Полный перечень состояний объекта и правила перехода между ними.
- Правила и расчёты. Как определяется согласующий, как считается срок, откуда берётся сумма или норматив.
- Уведомления. Кто получает сообщение, в какой момент и по какому каналу.
- Поведение при ошибках. Что видит пользователь при пустом обязательном поле, недоступной смежной системе, слишком большом файле.
- Журнал действий. Нужен ли и в каком объёме. Добавить его в готовое приложение означает вернуться ко всем операциям.
Нефункциональные требования для внутреннего приложения обычно скромны, и это хорошая новость. Одновременных пользователей десятки, и запас по нагрузке в требованиях чаще всего лишний расход.
Нужно ли ТЗ и в каком виде
Ответ зависит от того, кто принимает работу и есть ли конкурс между исполнителями. Полезнее понимать, что описывать подробно, а что нет.
Подробное ТЗ по ГОСТ имеет смысл в двух случаях. Когда работу принимает третья сторона, которой нужен формальный документ, и когда проводится конкурс и предложения надо сравнивать. В остальных случаях описание процесса на нескольких страницах работает лучше, потому что его читают.
Что описываем | Насколько детально | Почему так |
Процесс и его исключения | Максимально подробно | Определяет объём и приживаемость |
Роли и видимость данных | Подробно, на примерах | Переделывается хуже всего |
Данные и связи | Подробно | От модели данных зависит остальное |
Интеграции | Подробно, с состоянием чужих систем | Самая непредсказуемая часть |
Экраны и расположение элементов | Крупными штрихами | Уточняется на живом приложении быстрее |
Дизайн | Требованиями, не макетами | Для внутренней системы важнее плотность данных |
Технологии | Не описываем | Выбор стека — забота исполнителя |
Подробное ТЗ по ГОСТ имеет смысл в двух случаях. Когда работу принимает третья сторона, которой нужен формальный документ, и когда проводится конкурс и предложения надо сравнивать. В остальных случаях описание процесса на нескольких страницах работает лучше, потому что его читают.
ЧТО АССИСТЕНТ ДЕЛАЕТ С ОПИСАНИЕМ
Постановка задачи превращается в структуру приложения
Описание процесса, собранное по пяти шагам выше, — ровно тот вход, с которым работает ассистент. Из ТЗ или из текста своими словами он собирает описание приложения на объектном языке платформы — сущности, поля, роли, экраны, маршруты, — проверяет его на валидность и возвращается к тем фрагментам, которые проверку не прошли. Цикл повторяется, пока всё описание не пройдёт валидацию целиком, и только после этого платформа собирает приложение.
Отсюда практическое следствие для постановки задачи. Чем полнее описаны роли, ветвление и исключения, тем меньше остаётся мест, где структура достраивается по общим представлениям о таких процессах. В приложение попадает то, что заявлено в задании.
Постановка задачи превращается в структуру приложения
Описание процесса, собранное по пяти шагам выше, — ровно тот вход, с которым работает ассистент. Из ТЗ или из текста своими словами он собирает описание приложения на объектном языке платформы — сущности, поля, роли, экраны, маршруты, — проверяет его на валидность и возвращается к тем фрагментам, которые проверку не прошли. Цикл повторяется, пока всё описание не пройдёт валидацию целиком, и только после этого платформа собирает приложение.
Отсюда практическое следствие для постановки задачи. Чем полнее описаны роли, ветвление и исключения, тем меньше остаётся мест, где структура достраивается по общим представлениям о таких процессах. В приложение попадает то, что заявлено в задании.
- полнота описания важнее его формы: подойдёт и ЧТЗ, и текст своими словами
- пропущенные ветви видно на первом же прогоне, а не на приёмке
Роли и права: почему это решается до старта
Отдельная глава, потому что это самая частая причина переделок в корпоративных приложениях.
Плоские роли — администратор, сотрудник, наблюдатель — закладываются один раз и стоят недорого. Дорожает другое, права, зависящие от данных. Руководитель филиала видит только свой филиал. Менеджер — только своих клиентов. Закупщик видит все заявки, но суммы только до своего порога.
Такие права затрагивают каждый запрос к данным и каждый экран, поэтому их стоимость не складывается с остальным объёмом, а умножается на него. И добавить их задним числом означает пересобрать выборки во всём приложении.
Три вопроса, на которые надо ответить до старта.
Плоские роли — администратор, сотрудник, наблюдатель — закладываются один раз и стоят недорого. Дорожает другое, права, зависящие от данных. Руководитель филиала видит только свой филиал. Менеджер — только своих клиентов. Закупщик видит все заявки, но суммы только до своего порога.
Такие права затрагивают каждый запрос к данным и каждый экран, поэтому их стоимость не складывается с остальным объёмом, а умножается на него. И добавить их задним числом означает пересобрать выборки во всём приложении.
Три вопроса, на которые надо ответить до старта.
- Кто видит чужие данные и на каком основании. Руководитель видит подчинённых, контролёр видит всех, аудитор видит историю.
- Что происходит при переводе и увольнении. Права меняются вслед за должностью, доступ закрывается в день увольнения, а данные остаются.
- Кто замещает согласующего в отпуске. Требование звучит просто и реализуется сложнее, чем кажется, поэтому его лучше назвать сразу.
Данные и интеграции
Корпоративное приложение почти никогда не живёт в одиночестве, и от связей зависит, станет оно частью рабочего контура или ещё одним местом ручного ввода.
Учётная система. Чаще всего 1С, и обмен с ней есть почти в каждом проекте. Решить надо три вещи — какие данные считаются главными и где они живут, как часто идёт синхронизация, что делает приложение, когда учётная система недоступна.
Единый вход. Сотрудник заходит под той же учётной записью, что и в остальные системы компании. Для администратора это означает, что права заводятся один раз, а при увольнении доступ закрывается сразу во всём контуре.
Почта и мессенджеры. Уведомления, иногда приём заявок. Простая часть, которая заметно влияет на приживаемость.
Отдельно про хозяина данных. У каждой сущности должна быть одна система, которая имеет право её менять, остальные получают данные на чтение. Нарушение этого правила выглядит удобным на старте и через полгода приводит к тому, что никто не может сказать, какая запись верная.
Учётная система. Чаще всего 1С, и обмен с ней есть почти в каждом проекте. Решить надо три вещи — какие данные считаются главными и где они живут, как часто идёт синхронизация, что делает приложение, когда учётная система недоступна.
Единый вход. Сотрудник заходит под той же учётной записью, что и в остальные системы компании. Для администратора это означает, что права заводятся один раз, а при увольнении доступ закрывается сразу во всём контуре.
Почта и мессенджеры. Уведомления, иногда приём заявок. Простая часть, которая заметно влияет на приживаемость.
Отдельно про хозяина данных. У каждой сущности должна быть одна система, которая имеет право её менять, остальные получают данные на чтение. Нарушение этого правила выглядит удобным на старте и через полгода приводит к тому, что никто не может сказать, какая запись верная.
Этапы и сроки
Порядок работ одинаков у всех способов, различается длительность каждого этапа.
Два этапа, которые сокращают чаще всего, — разбор задачи и пилот. Первое возвращается переделками, второе переносит обнаружение проблем на всю компанию сразу.
Отдельная часть срока не зависит от исполнителя вовсе. Согласование доступа к данным, разрешение подключить отдел, решение службы безопасности. Запускать это надо параллельно со стартом работ.
Полезно заранее назвать дату, к которой приложение должно работать, и проверить её на реалистичность обратным счётом. Отнимите три недели пилота, время на приёмку и обучение, срок на доступы — и посмотрите, что остаётся на сборку. Часто выясняется, что дата недостижима не из-за разработки, и разговор об этом до старта дешевле, чем перенос в середине проекта.
Этап | Что происходит | Что зависит от вас |
Разбор задачи | Исполнитель выясняет процесс, роли, данные, исключения | Доступность человека, который знает процесс |
Проектирование | Модель данных, маршруты, права, экраны | Быстрые решения по спорным местам |
Сборка | Появляется работающее приложение | Готовность отвечать на вопросы |
Интеграции | Подключение к учётным системам | Доступы и человек, знающий эти системы |
Тестирование | Проверка сценариев, ролей, отказов | Проверка на своих кейсах |
Пилот | Один отдел работает по-настоящему | Отдел, согласившийся участвовать |
Запуск | Все пользователи, доступы, обучение | Решение, кто ведёт систему дальше |
Два этапа, которые сокращают чаще всего, — разбор задачи и пилот. Первое возвращается переделками, второе переносит обнаружение проблем на всю компанию сразу.
Отдельная часть срока не зависит от исполнителя вовсе. Согласование доступа к данным, разрешение подключить отдел, решение службы безопасности. Запускать это надо параллельно со стартом работ.
Полезно заранее назвать дату, к которой приложение должно работать, и проверить её на реалистичность обратным счётом. Отнимите три недели пилота, время на приёмку и обучение, срок на доступы — и посмотрите, что остаётся на сборку. Часто выясняется, что дата недостижима не из-за разработки, и разговор об этом до старта дешевле, чем перенос в середине проекта.
Сколько это стоит
Подробный разбор сметы — тема отдельного разговора, здесь достаточно понимать, что двигает бюджет корпоративного приложения. Пять множителей, и первые два весят больше остальных.
Что почти всегда забывают посчитать, кроме самой разработки. Время своих сотрудников на постановку и приёмку, миграцию и чистку данных, обучение и владение системой на горизонте трёх лет. Последняя часть обычно больше стоимости создания.
Полный расчёт с тремя бюджетами и владением за три года — отдельный разбор стоимости корпоративного приложения.
- Число сущностей и связей. Приложение с тремя объектами и приложение с десятью отличаются не пропорционально, а сильнее.
- Права, зависящие от данных. Умножаются на объём приложения, а не добавляются к нему.
- Интеграции. Единственная часть, стоимость которой определяет состояние чужих систем.
- Число маршрутов и исключений. Каждое ветвление добавляет и сборку, и тестирование.
- Требования к контуру. Размещение на своих серверах, отдельные требования безопасности.
Что почти всегда забывают посчитать, кроме самой разработки. Время своих сотрудников на постановку и приёмку, миграцию и чистку данных, обучение и владение системой на горизонте трёх лет. Последняя часть обычно больше стоимости создания.
Полный расчёт с тремя бюджетами и владением за три года — отдельный разбор стоимости корпоративного приложения.
Как обосновать бюджет
Гайд читает не покупатель на рынке, а человек, который должен защитить решение перед финансовым директором. Обоснование строится на четырёх величинах, и все четыре замеряются до проекта.
Считать удобно так. Возьмите годовой объём случаев, умножьте на время участников и стоимость часа — получится текущая стоимость процесса. Вычтите ожидаемое сокращение и стоимость владения решением. Точность такого расчёта невысокая, и его задача другая — показать порядок величины и понять, окупается проект в разы или в процентах.
Часть эффекта в эту арифметику не попадает, и на защите бюджета её формулируют словами. Устойчивость процесса — он перестаёт останавливаться из-за отсутствия конкретного сотрудника. Управляемость — руководитель видит, где стоит работа, без запроса отчёта. Готовность к проверке — история решений хранится и восстанавливается. Такие аргументы идут отдельным абзацем после расчёта, и на защите они нередко весят больше цифры.
Что мерим | Как замерить сейчас | Что показывает |
Время цикла | Календарный срок от начала до результата по десяти последним случаям | Насколько процесс ускорится |
Ручной труд | Сколько человеко-часов уходит на перенос и сверку данных | Что освободится |
Доля ошибок | Сколько случаев из ста уходит на переделку | Стоимость качества |
Стоимость операции | Время участников на один случай × стоимость часа | Экономию в деньгах на годовом объёме |
Считать удобно так. Возьмите годовой объём случаев, умножьте на время участников и стоимость часа — получится текущая стоимость процесса. Вычтите ожидаемое сокращение и стоимость владения решением. Точность такого расчёта невысокая, и его задача другая — показать порядок величины и понять, окупается проект в разы или в процентах.
Часть эффекта в эту арифметику не попадает, и на защите бюджета её формулируют словами. Устойчивость процесса — он перестаёт останавливаться из-за отсутствия конкретного сотрудника. Управляемость — руководитель видит, где стоит работа, без запроса отчёта. Готовность к проверке — история решений хранится и восстанавливается. Такие аргументы идут отдельным абзацем после расчёта, и на защите они нередко весят больше цифры.
Внедрение и приживаемость
Приложение, которым не пользуются, — самый дорогой из возможных исходов, потому что деньги потрачены, а процесс остался прежним. Приживаемость обеспечивается четырьмя вещами, и ни одна из них не техническая.
Владелец из бизнеса. Человек, которому нужен результат, — не тот, кто отвечает за внедрение системы. Если проект ведёт ИТ-служба, приложение воспринимается как чужое.
Пилот на одном отделе. Не на самом продвинутом и не на самом проблемном, а на типичном. Три недели работы дают картину, которую не даст ни один опрос.
Право поменять. Люди должны увидеть, что их замечания приводят к изменениям. Первые две недели после запуска — самое дешёвое время для правок и самое ценное для доверия.
Закрытие обходных путей. Пока старый способ работает, часть людей останется на нём. Это не саботаж, а нормальное поведение, и решается оно решением руководителя, не настройкой приложения.
Признак, по которому видно, что приложение прижилось. Через месяц после запуска люди приходят не с жалобами, а с просьбами добавить функции. Это значит, что систему считают своей.
И одна вещь про обучение, которую обычно недооценивают. Инструкция на десять страниц не работает — её не читают. Работает короткая встреча на полчаса, где человек из отдела сам проходит свой сценарий под присмотром, плюс один сотрудник внутри отдела, к которому можно подойти с вопросом. Такой сотрудник появляется сам, если его назвать и договориться, что это часть его работы на первые две недели.
Владелец из бизнеса. Человек, которому нужен результат, — не тот, кто отвечает за внедрение системы. Если проект ведёт ИТ-служба, приложение воспринимается как чужое.
Пилот на одном отделе. Не на самом продвинутом и не на самом проблемном, а на типичном. Три недели работы дают картину, которую не даст ни один опрос.
Право поменять. Люди должны увидеть, что их замечания приводят к изменениям. Первые две недели после запуска — самое дешёвое время для правок и самое ценное для доверия.
Закрытие обходных путей. Пока старый способ работает, часть людей останется на нём. Это не саботаж, а нормальное поведение, и решается оно решением руководителя, не настройкой приложения.
Признак, по которому видно, что приложение прижилось. Через месяц после запуска люди приходят не с жалобами, а с просьбами добавить функции. Это значит, что систему считают своей.
И одна вещь про обучение, которую обычно недооценивают. Инструкция на десять страниц не работает — её не читают. Работает короткая встреча на полчаса, где человек из отдела сам проходит свой сценарий под присмотром, плюс один сотрудник внутри отдела, к которому можно подойти с вопросом. Такой сотрудник появляется сам, если его назвать и договориться, что это часть его работы на первые две недели.
Импортозамещение и требования к контуру
Для компаний под требованиями регулятора или участвующих в госзакупках происхождение решения — часть технического выбора.
Что проверяют чаще всего. Наличие записи в реестре отечественного ПО у используемой платформы. Место размещения приложения и данных. Отсутствие зависимости от зарубежных облачных сервисов в критичных частях. Если в приложении обрабатываются персональные данные, добавляются требования 152-ФЗ к месту хранения и к передаче.
Про реестр стоит понимать одну вещь. Он говорит о формальном соответствии требованиям и ничего не сообщает о пригодности решения для вашей задачи — через реестр проходит большинство российского рынка. Читать его надо как фильтр, а не как оценку качества.
Отдельный вопрос, который стал актуальным с распространением ИИ в корпоративных системах. Если в решении используется языковая модель, стоит выяснить, какая именно и где она работает. Отечественные модели и размещение в России снимают этот вопрос заранее.
Что проверяют чаще всего. Наличие записи в реестре отечественного ПО у используемой платформы. Место размещения приложения и данных. Отсутствие зависимости от зарубежных облачных сервисов в критичных частях. Если в приложении обрабатываются персональные данные, добавляются требования 152-ФЗ к месту хранения и к передаче.
Про реестр стоит понимать одну вещь. Он говорит о формальном соответствии требованиям и ничего не сообщает о пригодности решения для вашей задачи — через реестр проходит большинство российского рынка. Читать его надо как фильтр, а не как оценку качества.
Отдельный вопрос, который стал актуальным с распространением ИИ в корпоративных системах. Если в решении используется языковая модель, стоит выяснить, какая именно и где она работает. Отечественные модели и размещение в России снимают этот вопрос заранее.
Типичные ошибки
- «Нам нужна система». Задача без процесса и без метрики не оценивается и не внедряется.
- Всё сразу. Проект на пять процессов и три подразделения даёт результат через год и теряет право на ошибку.
- Пропущенный разбор задачи. Проект начали по короткому описанию, требования выяснялись по ходу, и половина сборки ушла в переделку.
- Роли на потом. Права, зависящие от данных, добавляются задним числом хуже всего и означают переделку выборок.
- Проект без владельца из бизнеса. Приложение сдаётся ИТ-службе и остаётся ничьим.
- Автоматизация того, что стоило отменить. Прежде чем описывать согласование из четырёх подписей, полезно спросить, зачем их четыре.
Покажем Nolan на вашем процессе
Свяжемся в течение одного рабочего дня. Без спама.
Опишите задачу — мы разберём ваш процесс и подготовим демо-приложение на его основе
1
Вы оставляете заявку и кратко описываете задачу
2
Мы разбираем процесс или ЧТЗ
3
Показываем демо работающего приложения
Наши продукты:
Программа для ЭВМ «Nolan»
Программа для ЭВМ «CDP.Light»
Программа для ЭВМ «Корпоративный портал»
Компания «Технологии возврата»
3 года занимается разработкой и развитием ИИ
Из описания — в готовое приложение