Кто о чём. А я о наболевшем.
Я недавно была просто наблюдателем. Ситуация такая.
Одним очень хорошим людям нужно, чтобы автоматизировался процесс. Договорились с программистами. И тут… совершенно случайно. А случайности не случайны. Тут я вижу документ, который будут брать в работу. Техническое задание на продукт автоматизации. 11 страниц.Больше 10 лет назад я, врач по образованию, научилась описывать требования к автоматизации процессов. И это всегда по стандарту. Любой проект должен пройти ряд контрольных точек. А уж создание какого-то программного продукта — тем более.
Я не умею так работать.
Но не виню программистов. Им всегда надо сэкономить ресурсы и сделать по минимуму.
Как часто люди не понимают друг друга, порой видно именно в таких вот ТЗ.
Заказчик не может точно сказать, что он хочет. Хочет, чтобы «было и всё». А программист не хочет и не может вникать в тонкости процессов заказчика.
И получается… большой блокнот.
Туда что-то можно внести. Кнопочки работают. Но — они бесполезны. Не ясен ход процесса. Не настроен доступ. Не формируются показатели, которые бы говорили «ок» или «не ок» в процессе. Не видно маршрута документов, ресурсов и людей…
И вроде бы получили то, что хотели. А работать с этим невозможно. И толку от такой автоматизации процессов? Никакого.Какие это точки:
1. Предпроектное исследование. Когда мы смотрим процесс «as is». Мы изучаем нормативную базу процесса, чтобы соблюсти все юридические моменты.
2. Сбор требований. У непосредственных участников процесса мы собираем требования. Как бы им хотелось работать без бумаги. Какие на выходе данные они хотят видеть. И как ими управлять. Это часто похоже на описание какой-то сказки или идеала. И не всегда реализуемо. Но в этом и есть функция таких «переводчиков», как я. Мы погружены в процесс и одновременно можем описать с точки зрения программиста, какие поля и какие типы спецификаций необходимы.
3. Описание процесса «to be». В том числе графическая диаграмма того процесса, который мы хотим, чтобы был. И тут я всегда применяю инструменты бережливого производства: универсальные инструменты визуализации, потока, JIT, канбан и др.
4. Формирование требований к качеству новой системы или программы. Какие данные будут говорить нам о том, что система работает корректно.
5. Описание форм и вкладок. Это необязательно. Но визуальное представление часто корректирует второй пункт.
Диалог, интервьюирование, наблюдение, замеры времени, хронометраж, фотографирование рабочих и офисных процессов — это только часть инструментов, которые мы обязательно используем.
Один процесс описывается в 50-страничном документе. С диаграммами и таблицами спецификаций. С устранёнными потерями в потоке.
Я это обожаю делать. И учу своих коллег.
С уважением, lean-эксперт, Виктория Шуплецова
#автоматизация #бизнесбезбумаги #бережливоепроизводство #lean #канбан #justintime #управлениепроцессами #цифровизация #большойблокнот #бизнескакесть