SmartFlow | Аудит и автоматизация бизнеса

Сначала была идея. Потом — МФТИ. А сегодня — договор на разработку ПО.

Вчера у меня был выпускной в МФТИ. 🎓

Получила удостоверение о повышении квалификации по направлению «Бизнес-аналитик».
Но эта история началась гораздо раньше.

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

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

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

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

А удостоверение из МФТИ стало приятным подтверждением ещё одного пройденного этапа. 💙

#SmartFlow_Будни #SmartFlow_Аналитика

Третья версия ТЗ: от вопросов к дорожной карте

Сегодня отправляем нашему первому коммерческому заказчику третью редакцию технического задания.

За ней — несколько раундов обсуждений, подробный опросник по функциональным требованиям, ответы заказчика и lополнительные уточнения.
Почему уже третья версия?

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

Такие детали влияют не только на интерфейс, но и на структуру данных, права доступа и логику работы системы.

В новой редакции появился ещё один важный элемент — дорожная карта разработки.

Теперь мы не просто описываем, что должна уметь система, но и определяем последовательность реализации.

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

Дорожная карта связывает требования с будущими этапами разработки и помогает обеим сторонам понимать объём предстоящих работ.

При этом документ ещё не утверждён. Мы направляем его заказчику на очередной этап согласования.

Для нас хорошее ТЗ — не документ, который удалось написать с первого раза. Это документ, по которому заказчик и разработчик одинаково понимают, что именно предстоит создать.

И сегодня мы сделали ещё один шаг к этому результату.

#SmartFlow_Аналитика #SmartFlow_Практика

Простой бот или полноценная система? Разница — в требованиях

Продолжаем согласование технических заданий по двум проектам.

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

Функциональность стала компактнее. Но это по-прежнему информационная система.

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

И здесь возник интересный вопрос.

А можно ли всё это собрать на готовом конструкторе чат-ботов?

Мы проанализировали требования и подготовили для заказчика пояснительную записку.

Наш вывод: типовой конструктор сам по себе не гарантирует реализацию всего необходимого функционала.

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

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

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

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

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

В одном проекте пересматриваем архитектурный подход. В другом — детализируем поведение системы.

Бизнес-анализ помогает не просто определить, что нужно разработать, но и обосновать, почему выбранное решение подходит для задачи.

Не только автоматизация. Ещё и социальное предпринимательство.

Пока ждём ответы на опросник от первого коммерческого заказчика и согласование ТЗ по другому проекту, занимаемся развитием собственной компании.

Сегодня заполняю анкету для размещения информации о нашем предприятии на московской «Витрине социальных предприятий».

А началась эта история ещё в июле.
Именно тогда ООО «Горизонт событий», под брендом которого мы развиваем SmartFlow Tech, получило официальный статус социального предприятия по четвёртой категории.

Что это означает?

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

Для нас это направление не случайное.
Мы разрабатываем цифровые инструменты для организаций, которым нужна автоматизация процессов, но которые не всегда могут позволить себе сложные и дорогие информационные системы.
В том числе для небольших НКО и организаций, помогающих семьям и детям.

При этом SmartFlow Tech работает не только с социальным сектором. Бизнес-анализ, проектирование процессов и разработка цифровых решений нужны и коммерческим компаниям.

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

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

Получить статус — один этап.
Сохранить его и подтвердить результатами своей деятельности — уже постоянная работа.

Сейчас готовим информацию для размещения на «Витрине социальных предприятий» Москвы.

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

Три анкеты — ещё не техническое задание

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

Для этой работы подготовили опросный лист по разделу ТЗ: 42 вопроса, сгруппированных по трём этапам разработки.

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

Казалось бы, формы уже есть. Значит, остаётся перенести их в электронный вид?
Не совсем. 🙂

Например, сенсорный опросник содержит 77 вопросов в 10 блоках. Для ответов предусмотрены варианты «часто», «иногда», «редко».
Но в полученном документе нет правил подсчёта баллов и интерпретации результатов.

А значит, мы не можем просто придумать формулу и объявить её диагностическим показателем.

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

Или родительский анамнез.
Когда его заполнять? Сразу при обращении или позже, в личном кабинете? Можно ли сохранить черновик? Что делать, если родитель не помнит ответ? Кто вправе изменять уже внесённые сведения?

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

Электронная анкета — это форма ввода данных. А информационная система начинается там, где определены правила работы с этими данными.

Именно этим сейчас и занимаемся.

ТЗ ещё согласовывается, а архитектура уже уточняется

Сегодня начинаем согласование технического задания с нашим первым коммерческим заказчиком.И параллельно вносим в документ изменения.

Причина — нашли новый вариант решения задачи аутентификации пользователей: связку MAX + Passkey.
Для нашей платформы это важная часть архитектуры.Системой
будут пользоваться родители, специалисты и координаторы.

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

Passkey интересен нам как технология входа без привычного пароля. А MAX рассматриваем как один из каналов взаимодействия пользователя с системой.

Но между «выглядит подходящим решением» и «можно включать в техническое задание» есть обязательный этап — проверка. Поэтому сегодня у нас ещё одна задача: регистрация нашего ООО в MAX как юридического лица, подготовка тестового бота и взаимодействие с технической поддержкой платформы.

Нужно выяснить, какие сценарии действительно поддерживаются API и что потребуется реализовать на нашей стороне.
Это нормальная часть бизнес-анализа и проектирования.

Техническое задание не должно фиксировать красивую идею, техническая реализуемость которой ещё не подтверждена.

Сначала проверяем возможности и ограничения. Затем уточняем требования и согласовываем решение с заказчиком.

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

#SmartFlow_Аналитика #SmartFlow_Архитектура

От технического решения — к коммерческому предложению

На этой неделе у нас появился ещё один небольшой, но важный этап в работе над платформой.

По программе в Ульяновске согласовали подготовленный нами технический документ и попросили оформить ответ в виде официального коммерческого предложения.

Казалось бы, что здесь сложного? Перенести описание функций и стоимость на бланк — и готово.

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

Затем — определить, какие возможности уже предусмотрены общей архитектурой платформы, а какие потребуют отдельной настройки или разработки.

И только после этого можно обоснованно оценивать объём работ.

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

Для Ульяновска, например, важны индивидуальные маршруты сопровождения, профили ребёнка и семьи, фиксация результатов и аналитика изменений.

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

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

И это хороший пример того, что бизнес-анализ заканчивается не на схеме процесса или техническом задании.

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


#SmartFlow_Аналитика #SmartFlow_Продукт

152-ФЗ — это не только про документы. Это ещё и про архитектуру.

Сейчас мы выбираем новую облачную инфраструктуру для нашей платформы.

И выясняется, что найти сервер с нужными характеристиками — далеко не вся задача. 🙂

Нам предстоит работать с данными семей и детей: анкетами, индивидуальными особенностями, результатами обследований, рекомендациями специалистов.

Часть этой информации может относиться к специальным категориям персональных данных.

А значит, ещё на этапе проектирования нужно учитывать требования 152-ФЗ «О персональных данных».
Что это означает для разработчика?

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

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

Поэтому выбор облака для нас — не просто поиск нового хостинга.

Мы оцениваем, насколько выбранная инфраструктура позволит реализовать необходимые меры защиты и выполнить требования законодательства.

При этом сама по себе аренда сервера у российского провайдера ещё не делает систему соответствующей 152-ФЗ.

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

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

#SmartFlow_Архитектура #SmartFlow_Аналитика

Инфраструктура меняется. Архитектура остаётся.

В разработке не всё всегда идёт в той последовательности, которую красиво нарисовали в плане. 🙂

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

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

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

Поэтому рассматриваем временное решение — развернуть dev-среду на домашнем сервере.

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

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

Система не должна зависеть от одного сервера настолько, чтобы его замена превращалась в новый проект.

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

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

Иногда движение проекта вперёд выглядит именно так. 🙂

#SmartFlow_Архитектура #SmartFlow_Разработка

Одна платформа. Две программы. Разная логика работы.

Сегодня у нас снова день бизнес-анализа. 🙂

Грантовый специалист заказчика прислала два документа с вопросами о цифровизации и технологическом партнёрстве.

Один — для проекта в Пятигорске, второй — для Ульяновска.

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

За двумя грантовыми программами стоят разные процессы.

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

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

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

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

И здесь хорошо видно, зачем мы изначально проектируем систему модульной.

Не нужно создавать отдельный программный продукт для каждой новой задачи.
Но и заставлять разные организации и программы работать по одному жёсткому сценарию тоже неправильно.
Общая технологическая основа. Разные процессы. Разная конфигурация.
Именно так мы и хотим развивать SmartFlow.


#SmartFlow_Аналитика #SmartFlow_Архитектура