Proposal Мечтыоптимистическая пиэса в 2х актах с прологом и эпилогом презентация

Осень 2009, ver.1.0

В любой организации всегда найдется человек,
знающий, что на самом деле происходит.
Его-то и надо уволить.
Закон Конвэя
Все риски, связанные с получением знания,
предлагаемого в данной презентации,
читатель берет на себя.
Автор

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

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

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

Для упрощения восприятия слайдов введено большое количество анимации, поэтому
ПОЖАЛУЙСТА, НАЖМИТЕ F5, ЧТОБЫ ПЕРЕЙТИ В РЕЖИМ ПОКАЗА СЛАЙДОВ.
ТОЛЬКО ТАК ВЫ УВИДИТЕ ВСЕ, ЧТО ТАМ ЕСТЬ, И ВАМ ЛЕГКО БУДЕТ ЭТО ПРОЧИТАТЬ.

Используйте PAGE DOWN, чтобы продвигать показ ВПЕРЕД,
и PAGE UP, чтобы возвращаться НАЗАД.

Дорогие читатели! Соратники! Друзья!

6

Акт 2й 17

Эпилог 22

консалтинговой компании потенциальному Клиенту.
Содержит в том числе описание возможного проекта.

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

(И почему я только вышла за тебя? Потому что я согласился. – «Семейка Аддамс» © )

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

Перед вами – PROPOSAL МЕЧТЫ. (Наверное, вот такой проект мне всегда хотелось провести.)
Это описание идеального, с моей точки зрения, пути кардинального повышения эффективности бизнеса и его автоматизации. С чего следует начать. Как нужно вести. Что получить в итоге и как это использовать, чтобы результатом можно было гордиться.

КАК В ПЬЕСЕ, здесь для каждой реплики-действия указаны действующие лица, и сами реплики-действия расположены точно по сюжету.

Если Вы – Клиент, но у вас нет средств на все сразу, разбейте свое улучшение на несколько проектов, но соблюдите хотя бы последовательность – и вам уже будет счастье.

Если Вы консультант… ну, вам тоже должно быть интересно. И если свой Proposal Мечты вы видите иначе – напишите мне. Адрес – на последней странице.

задачи презентации.
Если вы сочтете описанное здесь логичным и приемлемым для себя,
это и будет главным аргументом «За» ☺ Адрес для дискуссий – в конце.

Допущение 2 (ключевое).

Интересна судьба того бизнеса, у которого есть главная цель
Этот бизнес успешен, если все его части работают на главную цель
Лишь тогда единая ИС, внедренная для той же главной цели, помогает бизнесу.

Поэтому, чтобы упорядочить и автоматизировать бизнес, нужно:

Определить главную цель всего бизнеса
Направить работу всех частей бизнеса в сторону главной цели
Внедрить ИС как средство контроля движения бизнеса в сторону главной цели

Допущение 3.
Из всех существующих методик повышения эффективности бизнеса (Activity-Based Costing, 6∑, etc.)
автор считает самой целесообразной методику Balanced Scorecard (BSC),
причем версии 3G (3го поколения. Не 1го, не 2го и не 4го). Поэтому 1й Акт посвящен внедрению BSC.

Допущение 4.
В ряде моментов автор позволил себе (см. Допущение 1) собственное толкование нюансов методики BSC
(например,заменив перспективу РАЗВИТИЕ на перспективу ЛЮДИ) как более, на его взгляд, логичное

Допущение 5.
Наиболее удачной методологией внедрения ПО (2й Акт) автор находит Oracle AIM (вернее, его прародителя).
Впрочем, и AIM присутствует в презентации исправленным и дополненным.

…Допущение 9: ВЫ НЕ МОРГАЕТЕ!

Допущение 6.
Вы знаете, что такое ROI, KPI, CEO, COO, CFO, ПО, КПД, и свободно оперируете сочетаниями из трех букв.

Допущение 7.
Вы кто-то из списка:
Руководитель, открытый к использованию современных бизнес-технологий
Руководитель или специалист, организующий внедрение ИС
Руководитель и специалист, оптимизирующий и развивающий бизнес
CEO, у которого есть время это читать
Вам просто любопытно

Допущение 8.
Вы будете читать вдумчиво и последовательно.
Информация сжата, и проскочив чуть-чуть, легко потерять нить совсем.
Следите за мыслью!

И последнее, самое важное…

УДАЧИ.

прочесть

несколько
ПОЯСНИТЕЛЬНЫХ СЛАЙДОВ

Внедрение: КАК?

Рассмотрим внедрение BSC
на примере одной очень гипотетической
маленькой, но гордой авиакомпании

для достижения целей

Принятие решений для достижения целей

Принятие решений для достижения целей

УРОВЕНЬ 1

УРОВЕНЬ 2…

…УРОВЕНЬ N

Исполнение решений

УРОВЕНЬ N+1 (Крайний)

На каждом уровне деятельность рассматривается в 4х перспективах:

Перспектива (Theme) ЛЮДЕЙ. Влияет на перспективу ПРОЦЕССОВ – чтобы процессы выполнялись, как задумано, люди должны быть обучены, подготовлены и мотивированы.

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

1й Акт (из 2)

готовит РЕЗУЛЬТАТЫ)
Заказчики РЕЗУЛЬТАТОВ (Ставят ЦЕЛИ, будут пользоваться РЕЗУЛЬТАТАМИ,
поэтому проверяют их качество)


Проектная группа должна быть создана
из людей со знаниями и навыками в областях:
Управления проектом (Планирование работ группы и управление их выполнением)
Бизнес (Возбуждающая ветвь: все процессы, которые приносят доходы)
Финансы (Тормозящая ветвь: все процессы, которые снижают расходы)
IT (Построение работы с данными для получения РЕЗУЛЬТАТОВ)

Инициирование Драйверов:
Проектная группа: 1. CEO назначает руководителя ПГ
2. Руководитель набирает команду (внутренний рекрутинг,
найм, аутсорсинг,
приглашенные консультанты)
Заказчики РЕЗУЛЬТАТОВ Принятыми в Компании средствами
CEO мотивирует Заказчиков участвовать в воркшопах
и нести ответственность за РЕЗУЛЬТАТ

Часть навыков может быть совмещена в одном специалисте.

Главное, чтобы количество специалистов проектной группы
соответствовало объему работ.

На успешных проектах размер проектной группы
около 5% от общего количества персонала.

Команда
внедрения BSC
сформирована

1й Акт (из 2)

примера, своя для каждой организации

ОРАНЖЕВАЯ Гамма

- часть процесса внедрения BSC, стандартна для всех

РЕЗУЛЬТАТЫ:
Пока только для Стратегического Уровня
Подготовленные Проектной Группой
Согласованные Заказчиками (СEO и пр.)
Документы с описаниями:
Дерева Целей
Генеральной Цели (Содержит Список KPI)

1й Акт (из 2)

нужно? (Objectives)

Как узнать, что достигли того, что нужно?

Прибыльность

Снижение
расходов

Рост
доходов

90%

+30% в год
15%

% прилетов
вовремя
Количество клиентов
% снижения при неизменной марже

<25 минут ___
94%
95%

Время наземного обслуживания
% вылетов вовремя
% удовлетворенных
клиентов

Повысить
оборачиваемость

Customer
Care

Рейсы
вовремя

Больше
клиентов

Снижение
цен

100%


100%

% подготовленных


% подготовленных

Согласован-
ность служб

Готовность
служб

Зеленая

Гамма

- часть примера, своя для каждой организации

ОРАНЖЕВАЯ Гамма

- часть процесса внедрения BSC, стандартна для всех

4%
-5% в год

+10% в год

Цели / Targets

Показатели / Measures

ROI
Себестоимость пассажиро-места
Доход на пассажиро-место

Разрабатываем Инициативы (Initiatives):

1й Акт (из 2)

РЕЗУЛЬТАТЫ:
Завершена обработка Стратегического Уровня.
Подготовлены Проектной Группой
Согласованы Заказчиками (СEO и пр.)
Документы с описаниями:
Действий по внедрению использования KPI
для контроля соответствия деятельности Генеральной Цели
Необходимых дополнительных организационных изменений
Списков KPI с описаниями
принципов расчета
ответственных за расчет
ответственных за соответствие KPI Целям

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

Зеленая

Гамма

- часть примера, своя для каждой организации

ОРАНЖЕВАЯ Гамма

- часть процесса внедрения BSC, стандартна для всех

X

- Сектор Дерева Целей

1

2

3

5

6

7

9

10

11

13

14

15

2

3

4

6

7

8

10

11

12

14

15

16

2

3

4

6

7

8

10

11

12

14

15

16

1

5

9

13

РЕЗУЛЬТАТ

1й Акт (из 2)

CMO
Директор по
Маркетингу

FO/D
Директор
Департамента
Полетов

SS/L
Руководитель
Продаж сервисов

FS/L
Руководитель
Продаж билетов

OPER/L
Руководитель
Операционной
Службы

FL/L
Менеджер развития
и поддержки
парка ВС

VP/S
Вице-Президент
по Продажам

CFO
Финансовый
директор

CEO
Генеральный
директор

COO
Исполнительный
директор

C/T
Руководитель
Службы
Тех. Сопровожден.

C/P
Командир
Отряда
Пилотов

SP/L
Руководитель
Отдела
Планирования

Tech
Служба
Технического
Сопровождения

Pilots
Отряд
Пилотов

Load
Служба Загрузки
Воздушных Судов
(ВС)

Ground
Служба
Наземного
Сопровождения

SP Dept
Отдел
Планирования
(полетов)

PR/L
Руководитель
Отдела Рекламы

PR Dept
Отдел Рекламы

CRM/L
Руководитель
Отдела работы
с клиентами

CRM
Отдел работы
с клиентами

Price/L
Руководитель
Отдела
Ценообразования

Pricing
Отдел
Ценообразования

Sales
Отделы продаж
билетов

Services
Отделы продаж
сервисов

POS
Пункты продаж
билетов

IT
Информационно-
Техническая
служба

OPER
Операционная
Служба

Legal
Юридический
Отдел

Treasury
Казначейство

Прямое
подчинение

Предоставляемый
сервис

* Структура обобщена и упрощена для целей иллюстрации процесса декомпозиции при построении Сквозного Дерева Целей BSC для всей организации

Возьмем для примера декомпозиции следующую структуру* :

1й Акт (из 2)

25-46) Этап 3. Пример Декомпозиции Целей

Зеленая

Гамма

- часть примера, своя для каждой организации

ОРАНЖЕВАЯ Гамма

- часть процесса внедрения BSC, стандартна для всех

Темы

C/T

C/P

SP/L

Tech

Pilots

Load

Ground

SP Dept

PR/L

PR Dept

CRM/L

CRM

Price/L

Pricing

Sales

Services

POS

IT

OPER

Legal

Treasury

CMO

FO/D

SS/L

FS/L

OPER/L

FL/L

VP/S

CFO

CEO

COO

C/T

C/P

G/L

SP/L

Tech

Pilots

Load

Ground

SP Dept

PR/L

PR Dept

CRM/L

Price/L

Pricing

Sales

Services

POS

IT

OPER

Legal

Treasury

Связное Дерево Целей
построено для всей организации!

неделю

Директор
Имелович
Исполнительный

Директор
Петрович
Полетов

Среднее отклонение

Не более 20 минут

Соответствовать расписанию

PS0.007

CT1.018

PT1.020

Тактический-1

ПРОЦЕССЫ

Повысить оборачиваемость

CT1.018

Тактический-1

КЛИЕНТЫ

Прилеты вовремя

PS0.007

Стратегический

ПРОЦЕССЫ

PT1.020.056

FY End

Aй Ти
Сержант

Ай Ти Джуниор

Регламент
импорта данных в BI

Частично

On-Line
около 20
раз в
День

Мени Джа
Граунд
Админский

Учет
движения
ВС

Время факт. посадок,
Расписание

Resource
Mgmnt
System
(типа GS)

Иван
Конт-
Роулинг

Выгрузка
в XLS и расчет выборки YY

Данные по полетам за
неделю

BI-система

(∑¡=1,n (abs(T_расчетное¡ - T_факт¡)))/n n - рейсов в неделю

ФИНАНСЫ
КЛИЕНТЫ
ПРОЦЕССЫ
или ЛЮДИ

Стратегический
Тактический (с уточнением под-уровня) или
Операционный

Уникальный идентификатор цели. Например,
по шаблону: «Код перспективы»-«Код уровня»-«Номер под-уровня»-«Порядковый номер»

На эту цель
перспективы КЛИЕНТОВ
влияет данная

Достижение
этой цели более верхнего уровня
зависит от
достижения
данной

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

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

Информационная система, откуда нужно взять данные для расчета KPI

Какой механизм должен быть реализован в системе

Кто рассчитывает KPI и предоставляет данные Ответственному и Куратору

Информационная система, где отражаются данные о деятельности, контролируемой данным KPI

Сотрудники, владельцы бизнес-процесса,
ответственные за внесение данных в систему

Бизнес-процесс, в котором нужные данные появятся в системе

Что необходимо внедрить, чтобы у Ивана Конт-Роулинга вовремя появлялись данные для расчета?

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

Требования к ПО,
которое необходимо внедрить
для реализации BSC
(Требования к ПО для BSC)
(вход для 2го акта)

1й Акт (из 2)

определены:
Стремления и цели для ВСЕХ (Чего хотим достичь – качественно и количественно)
Методы контроля достижения Целей (Кто кого должен контролировать и кто что считать)

Теперь нужно начать этим пользоваться. Для этого:
CEO ставит задачи и сроки Ответственным-за-Инициативы
(в первую очередь за адаптирующие Инициативы, критичные для собственно расчета KPI)
приступить к реализации Инициатив. (Деятельность Ответственных-за-Инициативы управляется
по модели достаточно стандартного процесса внутренней проектной деятельности)
На основе задокументированных РЕЗУЛЬТАТОВ BSC
принятыми в Компании процедурами (Приказ, мэйл, открытый пункт в софте документооборота,
присесть на край стола и проникновенно сказать…)
CEO ставит задачу всем КТО-ответственным и КОМУ-ответственным
с такого-то числа (определяемого выполнением адаптирующих Инициатив) начать с указанной Частотой по указанному Графику
отчитываться о достижении своих Целей.
CEO также ставит задачу руководству Ответственных за расчет KPI
с такого-то числа организовать всех Ответственных
в соответствии с РЕЗУЛЬТАТАМИ BSC. (Считающие KPI должны быть частью
структуры-сервиса, обслуживающей КТО-ответственных,
но им не подчиняющейся)
КТО-ответственные сами делают запросы Ответственным за расчет KPI и согласовывают с ними процессы предоставления KPI-отчетности в соответствии с Частотой и Графиком.
С тех КТО-ответственных, у кого КОМУ-ответственный сам CEO, он начинает спрашивать лично.

Сам процесс прост: При обнаружении несоответствия KPI нужному значению
КТО-Ответственный (каждый! важно) генерирует решение и программу действий на исправление ситуации,
(для этого он анализирует KPI деятельности своих подчиненных КТО-Ответственных)
получает подтверждение того, КОМУ-Ответственный, и действует.
После чего анализирует прогресс в следующий замер KPI – и так в цикле.

Balanced
Score Card
ВНЕДРЕНА

в фазе BSC целей,
решение о внедрении новых IT-средств принимается так:

ВНЕДРЯТЬ, ЕСЛИ

Решение
внедрять ПО
Принято

2й Акт (из 2)

признана. Продукт выбирается так:

Собранные
в процессе
проекта
BSC
Требования
к ПО
для BSC
(выход
1го акта)

Требования, покрываемые
дополнительными
разработками

Стандартная
функциональность

Зависит от гибкости продукта
(долго ли его дорабатывать)
и от стоимости разработчиков
под данное ПО на рынке

Число бизнес-экспертов,
которых придется отрывать
от основной
деятельности;
Число специалистов по продукту,
которых придется
нанимать или приглашать извне

Бизнес,
который дорос до BSC,
слишком специфичен,
чтобы нашлось ПО, которое
подошло бы ему на 100%.
Поэтому фаза «доработок»
является
обязательным атрибутом
каждого серьезного
проекта внедрения

ПО
выбрано

2й Акт (из 2)

готовит ЗАПУСК – работоспособное ПО и подготовленных людей)
Владельцы Процессов (Верхний уровень руководства ответственных за расчет KPI –
см. РЕЗУЛЬТАТЫ BSC. Главные Заказчики ЗАПУСКА)

Проектная группа должна быть создана
из специалистов, играющих роли:
Руководителя проекта (Планирование работ и управление их выполнением)
ФА (Функционального Архитектора) (Специалиста по ПО в целом и по интеграции, главного идеолога IT-решения под заданные бизнес-требования)
ТА (Технического Архитектора) (Специалиста по hardware, главного идеолога решения по конфигурации оборудования под заданное IT-решение)
ПО-специалистов (Узких специалистов по отдельным областям функций ПО)
Бизнес-специалистов (Специалистов по отдельным областям бизнеса, которые предстоит автоматизировать – ответственных за KPI)
Разработчиков (Программистов, дорабатывающих ПО)

В процессе проекта Проектная группа создает Центр Поддержки (Состоит из системных администраторов ПО и собственных ПО-специалистов, способных решать текущие вопросы эксплуатации)

Для нужд проекта необходимы
Проектные окружения (ПО и hardware меньшей мощности для тестирования решений и настроек, ведения разработок, проведения потоковых тестов и обучений – 4 клона)
Промышленное окружение (ПО и hardware проектной мощности для нагрузочных тестирований и
собственно эксплуатации – 2 клона)

Часть ролей может быть совмещена в одном специалисте.

Главное, чтобы количество специалистов проектной группы
соответствовало объему работ.

На успешных проектах размер проектной группы
около 5% от общего количества персонала.

Могут быть приглашенными консультантами

Может быть приглашенным консультантом

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

Команда
внедрения ПО
сформирована

2й Акт (из 2)

Могут быть внешними специалистами

процессе
проекта
BSC
Требования
к ПО
для BSC
(выход
1го акта)

Проектирование и согласование решений

Подготовка-Тестирование ПО / Обучение

ЗАПУСК

Сбор требований

Проектные
окружения

Бизнес-
специалисты

Промышленное
окружение

Данные для
конвертации

Сценарий тестирования
процесса

Ряд критичных показателей, показывающих,что именно Заказчики проекта ждут от внедрения?
Должны проистекать из Инициатив. Пишет ФА, опираясь на требования Владельцев Процессов и Инициативы

Общая схема программного комплекса с отображением всех потоков данных, оценкой их объема, какие бизнес-функции обслуживает каждое ПО, общая структура учетных аналитик, прочие глобальные требования – функциональная валюта, базовые единицы измерения, шкала периодов и пр. Пишет ФА, опираясь на Инициативы и требования Владельцев Процессов

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

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

Проектная группа может оценить производительность системы только на точечных операциях. Чтобы понять, выдержит ли система реальную многопользовательскую нагрузку, нужно определить ряд узких мест и автоматизировать для них тестирование производительности
Пишут ФА и ТА, опираясь на Инициативы и требования Владельцев Процессов

Исходя из Стратегии Конвертации формируется список Объектов, которые нужно загрузить (сконвертировать) из старых данных в новые (незакрытые счета, остатки, клиенты, и т.п.). Для каждого объекта определяется метод загрузки – вручную (если немного), или стандартный механизм загрузки (если есть), или механизм, который нужно разработать (если много и стандартного нет)
Пишут ФА и ПО-специалисты, опираясь на Инициативы и требования Владельцев Процессов

Технические процессы – это фрагменты бизнес-процессов, которые требуют своего выполнения в системе. Заведение счета, резервирование дебиторки, амортизация ОС, etc. Впрочем, на уровне входящих-исходящих событий в тех.процессах прописывается связь с бизнесом – в каких именно ситуациях каждый процесс нужен и на что его результат влияет дальше.
Каждый процесс – это последовательность шагов, выполняемых в системах или вручную.
Пишут ФА и ПО-специалисты, опираясь на Инициативы и требования Владельцев Процессов

Поток – это цепь, в которую можно объединить несколько технических процессов, состыковав их по входящим-исходящим событиям. Каждая цепь обозначает непрерывную эстафету видоизменяемых внутри ПО данных. Разрыв в цепи означает невозможность двигаться дальше (например, нельзя принятыми деньгами закрыть дебиторку, если она не отражена в системе). Входы и выходы таких цепей должны быть самодостаточны. Например – «Клиент пришел и просит билет». Если какие-либо процессы висят в воздухе, или внутри цепей есть нестыкуемые пробелы – это повод доработать списки и границы процессов.
Пишут ФА и ПО-специалисты, опираясь на Инициативы и требования Владельцев Процессов

На базе сценария тестирования процесса нужно создать инструкцию выполнения процесса для пользователей.
Пишут ПО-специалисты

Тестирование отдельных расширений и отдельных процессов – проверка работоспособности выбранных решений как таковых. Используются «спотолочные» данные.
Тестируют ПО-специалисты и разработчики

Тестирование отдельных процессов с установленными расширениями уже на имеющих бизнес-смысл данных – анализ правильности выбранных решений с точки зрения бизнеса. Тестирование Конвертации.
Тестируют ПО-специалисты с бизнес-специалистами

Тестирование потоков с установленными расширениями уже на имеющих бизнес-смысл данных – анализ совместимости всех выбранных решений и правильности работы системы в целом с точки зрения бизнеса. Тестирование стратегии Конвертации в целом.
Тестируют бизнес-специалисты при помощи ПО-специалистов

Прогон отлаженных потоков руками будущих пользователей на имеющих бизнес-смысл (или реальных из прошлых периодов) данных. Самая эффективная форма обучения. Проверка корректности инструкций пользователей.
Проводят бизнес-специалисты при помощи ПО-специалистов

Загрузки данных ручным вводом или интерфейсами, требующими только настройки и подготовки загрузочного файла.
Пишут ПО-специалисты

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

Шаги процессов, осуществление в системе которых требует механизмов, которые еще нужно разработать. Пишут ПО-специалисты

Шаги процессов, осуществление которых в системе требует только настройки.
Пишут ПО-специалисты

ПО-специалисты при участии Бизнес-специалистов

Сотрудники Центра Поддержки, обучаемые ПО-специалистами

Разработчики

Сотрудники Центра Поддержки, обучаемые ПО-специалистами

По каждому шагу процесса делается вывод – реализуем ли он в системе стандартными средствами? Если НЕТ, нужно написать ТЗ на разработку расширения – дополнительной функциональности, выполняемой программистом проекта и встраиваемой в ПО. На каждую разработку формируется отдельный документ.
Конвертация через интерфейс загрузки рассматривается как отдельная разработка. Как и эмулятор ввода или обработки большого объема данных для нагрузочного тестирования.
Пишут ПО-специалисты опираясь на Инициативы и
требования бизнес-специалистов

По каждому шагу процесса делается вывод – реализуем ли он в системе стандартными средствами? Если ДА, нужно разработать и задокументировать, какие настройки нужно осуществить в системах для успешного выполнения данного шага. На каждый процесс формируется отдельный документ.
Конвертация вручную рассматривается как процесс ввода данных.
Пишут ПО-специалисты опираясь на Инициативы и
требования бизнес-специалистов

Функциональная часть документа описывает, для каких именно бизнес-требований нужно настроить в системе данные свойства.
Пишут ПО-специалисты опираясь на Инициативы и
требования бизнес-специалистов.

Техническая часть документа описывает, какие именно действия нужно осуществить в системе для реализации данных настроек.
Пишут ПО-специалисты опираясь на свое знание ПО

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

Функциональная часть документа описывает, для каких именно бизнес-требований нужно выполнить данную разработку.
Пишут ПО-специалисты опираясь на Инициативы и
требования бизнес-специалистов.

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

Сценарий тестирования расширения описывает необходимую последовательность действий и ожидаемые результаты, которые подтвердят правильность разработки.
Пишут ПО-специалисты опираясь на требования бизнес-специалистов.

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

Сценарии тестирования потоков – это «склеенные» сценарии тестирования процессов, объединенные общей бизнес-ситуацией (например, в одном процессе дебиторка создается, в другом создается оплата, в третьем дебиторка закрывается оплатой в ноль. Чтобы «склеить» это в поток, нужно создавать и счет и оплату на одного и того же клиента и оплата должна быть равна дебиторке).
Пишут ПО-специалисты опираясь на требования бизнес-специалистов.

В процессе написания ТЗ на настройку и ТЗ на разработку могут возникать взаимные требования, которые нужно фиксировать как закрытые вопросы, адресованные к автору второго документа (например, не выполнять такое-то действие в таком-то расширении, если в таком-то шаге процесса не заполнен такой-то параметр)

Программное
Обеспечение
ВНЕДРЕНО

CEO ОТДАЛ ПРИКАЗ О НАЧАЛЕ РАБОТЫ ПО НОВЫМ ПРОЦЕДУРАМ С ИСПОЛЬЗОВАНИЕМ НОВОГО ПО !

2й Акт (из 2)

Возможны несколько итераций
до тех пор, пока не станет ВСЕ OK

желания Главы Бизнеса навести порядок у себя на фирме
(ЧЕРЕЗ
осознанное желание и выбор способа
постановку согласованных целей
определения правил мониторинга
автоматизации исполнения этих правил)
К организации с согласованной деятельностью, вооруженной набором инструментов согласования.

Я бы рекомендовал СЕО или его окружению, ответственному за оптимизацию деятельности компании,
перед очередным намерением что-нибудь улучшить вспомнить то, что было здесь схематично набросано в 2х актах,
определить, на каком этапе НА САМОМ ДЕЛЕ находится ваша компания, и аккуратно начать с ближайшего следующего.

И удивление от диссонанса между вложением средств и полученным эффектом будет намного меньше, чем, например,
после того, как внедрить ERP вслепую, так и не определив Целей.

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

А участники вашей проектной группы скажут –
да, вот ради ЭТОГО и правда стоило работать месяцами по 14 часов в день.

Поздравляю! Дошли ☺

И будет всем счастье.