О Руслане
Понимаю бизнес-задачу и могу оценить, как её реализовать технически
Моя база — разработка бизнес-систем, интеграции, работа с данными и автоматизация.
Поэтому смотрю не только на идею, но и на данные, возможности текущих систем и реальную сложность внедрения.
Но начинаю не с технологии. Сначала — что тормозит бизнес, почему и стоит ли это вообще менять.
Как я работаю
Я не начинаю с вопроса «что внедрить?»
Одинаковая внешняя проблема может иметь разные причины.
Сотрудники долго ищут информацию — причина может быть в порядке работы, в данных, в самой системе или в передаче между системами.
- 01 Понять процесс
- 02 найти причину
- 03 оценить стоимость проблемы
- 04 сравнить варианты изменения
- 05 реализовать
- 06 измерить результат
Поэтому и менять можно по-разному: порядок работы, настройки системы, связь между системами, готовый продукт, своя разработка, AI.
Иногда менять технологию вообще не нужно.
Две стороны задачи
Важно понимать обе стороны задачи
Со стороны бизнеса
- что именно мешает работе
- сколько это происходит
- кто тратит время
- где возникают ошибки и ожидания
- что изменится для бизнеса
- как измерить результат
Со стороны реализации
- какие данные нужны
- где они находятся
- что уже умеют существующие системы
- какие ограничения есть
- нужна ли интеграция
- нужна ли разработка
- насколько изменение реально внедрить
Моя задача — связать эти два уровня и не потерять по дороге ни бизнес, ни технику.
Техническая база
Хорошая идея ещё должна работать в реальной компании
На бумаге изменение может выглядеть правильно, а в работе оказаться слишком сложным, дорогим или неудобным.
Поэтому смотрю не только на желаемый результат, но и на то, с какими данными и системами придётся работать.
Что проверяю до того, как идея станет проектом
- какие данные уже есть
- где они находятся
- что умеют текущие системы
- что можно изменить без разработки
- где достаточно настройки или интеграции
- где действительно нужна собственная разработка
- насколько сложно встроить это в ежедневную работу.
Проверяю, реализуема ли идея, до того как она станет дорогим проектом.
Практическая техническая база
- 01
Бизнес-системы
Где живут продажи, клиенты, документы и операционная работа.
- 02
Интеграции и API
Связать сервисы и передать данные между ними.
- 03
Автоматизация процессов
Убрать повторяющиеся действия, ручной перенос и лишние проверки.
- 04
Работа с данными
Собрать, привести в порядок и использовать нужные данные.
- 05
Разработка
Когда готового, настройки и интеграции уже не хватает.
- 06
Искусственный интеллект
Один из инструментов — для документов, текста и неоднозначных данных.
Ни один из них не обязателен в проекте.
Что интересно разбирать
Особенно интересны процессы, где дорогая работа смешана с рутиной
Смотрю внимательнее, если квалифицированный сотрудник заметную часть времени обслуживает сам поток работы, а не делает свою.
Ручная работа сама по себе не проблема. Проблема — когда она дорого стоит и мало что даёт.
Подробные разборы — на страницах о технических заявках и о выездном сервисе .
- менеджер собирает данные из нескольких систем
- инженер ищет и переносит уже известную информацию
- диспетчер вручную ведёт передачи и статусы
- один документ проходит через нескольких сотрудников
- ошибки и уточнения возвращают работу назад
- рост объёма сразу требует новых людей
Принципы
Три принципа, которых я стараюсь придерживаться
- 01
Не выбирать инструмент заранее
Сначала причина проблемы, потом технология.
- 02
Не обещать эффект до измерения
Сначала смотрю, как работает сейчас, и собираю цифры.
- 03
Не придумывать проект без экономики
Если изменение стоит дороже эффекта — делать его незачем.
Результат
Результат — не само внедрение
Новая система сама по себе ничего не доказывает.
Смысл появляется, когда бизнес получает понятный результат.
Если эффекта нет — проект не нужен.
- меньше времени сотрудников
- больше работы той же командой
- быстрее проходит процесс
- меньше ошибок и переделок
- быстрее получает ответ клиент
- штат растёт медленнее, чем объём
- выше управляемость процесса
Есть процесс, который стоит разобрать?
Техническое задание заранее не нужно.
Возьмём один реальный процесс, заявку или запрос и посмотрим, где проблема и есть ли смысл что-то менять.