'

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

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

2 Приятного просмотра ? Как читать эту презентацию Вы держите перед своими глазами (и своим умом) пособие по магическому переходу ОТ импульсивного желания Главы Бизнеса навести порядок у себя на фирме К организации с согласованной деятельностью, вооруженной набором инструментов согласования. Описание этого перехода укладывается в пару десятков слайдов, но это непростые слайды. Они охватывают сразу большие фрагменты картины. Развитие бизнеса – это медленное и трудное продвижение по пути, который вы прокладываете прямо на ходу по целине туманного будущего. Обидно, затратив столько сил, в итоге прийти не туда, не правда ли? Поэтому лучше сложные слайды, зато у вас на ладони будет все – все ваши асфальтоукладчики, обозы со стройматериалами, вертолет дальней разведки и ваш походный лимузин главнокомандующего. И будет ясно, что с этим всем делать и как применять. Для упрощения восприятия слайдов введено большое количество анимации, поэтому ПОЖАЛУЙСТА, НАЖМИТЕ F5, ЧТОБЫ ПЕРЕЙТИ В РЕЖИМ ПОКАЗА СЛАЙДОВ. ТОЛЬКО ТАК ВЫ УВИДИТЕ ВСЕ, ЧТО ТАМ ЕСТЬ, И ВАМ ЛЕГКО БУДЕТ ЭТО ПРОЧИТАТЬ. Используйте PAGE DOWN, чтобы продвигать показ ВПЕРЕД, и PAGE UP, чтобы возвращаться НАЗАД. Дорогие читатели! Соратники! Друзья!


Слайд 2

3 Содержание Пролог 4 Акт 1й 6 Акт 2й 17 Эпилог 22


Слайд 3

4 ПРОЛОГ (1/2). Почему Proposal Мечты? Почему пиэса? Proposal – это коммерческое предложение консалтинговой компании потенциальному Клиенту. Содержит в том числе описание возможного проекта. За свой период работы в консалтинге я видел много пропозалов, и все они описывали не то, что следовало бы делать, а то, за что Клиент был согласен заплатить. (И почему я только вышла за тебя? Потому что я согласился. – «Семейка Аддамс» © ) Все эти попытки начать с середины и чудом не закончить ничем оставляли горький привкус нереализованных возможностей, как собственных профессиональных, так и возможностей Клиента, для которого тоже можно было бы сделать больше и лучше. Перед вами – PROPOSAL МЕЧТЫ. (Наверное, вот такой проект мне всегда хотелось провести.) Это описание идеального, с моей точки зрения, пути кардинального повышения эффективности бизнеса и его автоматизации. С чего следует начать. Как нужно вести. Что получить в итоге и как это использовать, чтобы результатом можно было гордиться. КАК В ПЬЕСЕ, здесь для каждой реплики-действия указаны действующие лица, и сами реплики-действия расположены точно по сюжету. Если Вы – Клиент, но у вас нет средств на все сразу, разбейте свое улучшение на несколько проектов, но соблюдите хотя бы последовательность – и вам уже будет счастье. Если Вы консультант… ну, вам тоже должно быть интересно. И если свой Proposal Мечты вы видите иначе – напишите мне. Адрес – на последней странице.


Слайд 4

5 ПРОЛОГ (2/2). Девять допущений Допущение 1. Аргументация не входит в задачи презентации. Если вы сочтете описанное здесь логичным и приемлемым для себя, это и будет главным аргументом «За» ? Адрес для дискуссий – в конце. Допущение 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. Вы будете читать вдумчиво и последовательно. Информация сжата, и проскочив чуть-чуть, легко потерять нить совсем. Следите за мыслью! И последнее, самое важное… УДАЧИ.


Слайд 5

6 Акт 1 (из 2). Внедрение BSC (Balanced Score Card) Содержание CEO CEO Собственно, все ? Осталось прочесть несколько ПОЯСНИТЕЛЬНЫХ СЛАЙДОВ Внедрение: КАК? Рассмотрим внедрение BSC на примере одной очень гипотетической маленькой, но гордой авиакомпании


Слайд 6

7 Внедрение BSC. Термины Уровни деятельности Деятельность организации рассматривается на уровнях: 1й Акт (из 2)


Слайд 7

8 Внедрение BSC. Термины Перспективы деятельности Стратегический уровень Тактические уровни Операционный уровень ОПРЕДЕЛЕНИЕ СТРАТЕГИЧЕСКИХ ЦЕЛЕЙ УРОВЕНЬ 0 Принятие решений для достижения целей Принятие решений для достижения целей Принятие решений для достижения целей УРОВЕНЬ 1 УРОВЕНЬ 2… …УРОВЕНЬ N Исполнение решений УРОВЕНЬ N+1 (Крайний) На каждом уровне деятельность рассматривается в 4х перспективах: Перспектива (Theme) ЛЮДЕЙ. Влияет на перспективу ПРОЦЕССОВ – чтобы процессы выполнялись, как задумано, люди должны быть обучены, подготовлены и мотивированы. Все, что влияет на соответствие персонала производственным нуждам. Количество, качество и актуальность обучающих программ, мотивация именно той деятельности, которая востребована в процессах, etc. 1й Акт (из 2)


Слайд 8

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


Слайд 9

10 Внедрение BSC. КАК? (Шаги 1-16) Этап 1: Стратегический уровень. Цели. КАК? Зеленая Гамма - часть примера, своя для каждой организации ОРАНЖЕВАЯ Гамма - часть процесса внедрения BSC, стандартна для всех РЕЗУЛЬТАТЫ: Пока только для Стратегического Уровня Подготовленные Проектной Группой Согласованные Заказчиками (СEO и пр.) Документы с описаниями: Дерева Целей Генеральной Цели (Содержит Список KPI) 1й Акт (из 2)


Слайд 10

11 Внедрение BSC. КАК? (Шаги 17-24) Этап 2: Стратегический уровень. Инициативы Дерево Целей (Strategy Map) Что нужно? (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 Целям


Слайд 11

12 Внедрение BSC. КАК? Этап 3. Декомпозиция на другие уровни ФИНАНСЫ КЛИЕНТЫ ПРОЦЕССЫ ЛЮДИ ФИНАНСЫ КЛИЕНТЫ ПРОЦЕССЫ ЛЮДИ ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО ЦЕЛИ КТО Так как каждый сектор Дерева Целей привязан к Ответственным, удобно выполнять Декомпозицию сверху вниз по оргструктуре Зеленая Гамма - часть примера, своя для каждой организации ОРАНЖЕВАЯ Гамма - часть процесса внедрения 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)


Слайд 12

13 Тактические уровни Уровень 2 Внедрение BSC. КАК? Этап 3. Пример организационной структуры G/L Руководитель Наземной Службы 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)


Слайд 13

14 1й Акт (из 2) G/L CMO FO/D SS/L FS/L OPER/L FL/L VP/S CFO CEO COO Воркшоп, модерируемый участником проектной группы, с… Внедрение BSC. КАК? (Шаги 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 Связное Дерево Целей построено для всей организации!


Слайд 14

15 Внедрение BSC. РЕЗУЛЬТАТЫ Для ВСЕХ уровней и ВСЕХ перспектив получаем: По пятницам Раз в неделю Директор Имелович Исполнительный Директор Петрович Полетов Среднее отклонение Не более 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)


Слайд 15

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


Слайд 16

17 Акт 2 (из 2). Внедрение ПО (Программного обеспечения) Содержание Руководство ответственных за расчет KPI CIO


Слайд 17

18 Внедрение ПО. Нужно ли? Так как ПО должно работать на достижение поставленных в фазе BSC целей, решение о внедрении новых IT-средств принимается так: ВНЕДРЯТЬ, ЕСЛИ Решение внедрять ПО Принято 2й Акт (из 2)


Слайд 18

19 Стоимость лицензий Стоимость времени разработчиков Необходимое количество разработчиков Внедрение ПО. Таки нужно. КАКОЕ? Необходимость внедрять новое ПО признана. Продукт выбирается так: Собранные в процессе проекта BSC Требования к ПО для BSC (выход 1го акта) Требования, покрываемые дополнительными разработками Стандартная функциональность Зависит от гибкости продукта (долго ли его дорабатывать) и от стоимости разработчиков под данное ПО на рынке Число бизнес-экспертов, которых придется отрывать от основной деятельности; Число специалистов по продукту, которых придется нанимать или приглашать извне Бизнес, который дорос до BSC, слишком специфичен, чтобы нашлось ПО, которое подошло бы ему на 100%. Поэтому фаза «доработок» является обязательным атрибутом каждого серьезного проекта внедрения ПО выбрано 2й Акт (из 2)


Слайд 19

20 Внедрение ПО. КТО? Драйверами внедрения являются: Проектная группа (Определяет и выполняет, ЧТО нужно сделать, готовит ЗАПУСК – работоспособное ПО и подготовленных людей) Владельцы Процессов (Верхний уровень руководства ответственных за расчет KPI – см. РЕЗУЛЬТАТЫ BSC. Главные Заказчики ЗАПУСКА) Проектная группа должна быть создана из специалистов, играющих роли: Руководителя проекта (Планирование работ и управление их выполнением) ФА (Функционального Архитектора) (Специалиста по ПО в целом и по интеграции, главного идеолога IT-решения под заданные бизнес-требования) ТА (Технического Архитектора) (Специалиста по hardware, главного идеолога решения по конфигурации оборудования под заданное IT-решение) ПО-специалистов (Узких специалистов по отдельным областям функций ПО) Бизнес-специалистов (Специалистов по отдельным областям бизнеса, которые предстоит автоматизировать – ответственных за KPI) Разработчиков (Программистов, дорабатывающих ПО) В процессе проекта Проектная группа создает Центр Поддержки (Состоит из системных администраторов ПО и собственных ПО-специалистов, способных решать текущие вопросы эксплуатации) Для нужд проекта необходимы Проектные окружения (ПО и hardware меньшей мощности для тестирования решений и настроек, ведения разработок, проведения потоковых тестов и обучений – 4 клона) Промышленное окружение (ПО и hardware проектной мощности для нагрузочных тестирований и собственно эксплуатации – 2 клона) Часть ролей может быть совмещена в одном специалисте. Главное, чтобы количество специалистов проектной группы соответствовало объему работ. На успешных проектах размер проектной группы около 5% от общего количества персонала. Могут быть приглашенными консультантами Может быть приглашенным консультантом ? Не стоит пытаться создавать Центр Поддержки из людей Проектной Группы. Внедряют и поддерживают люди разных типов, и либо одним потом станет скучно и они уйдут, либо первые вначале не справятся… Команда внедрения ПО сформирована 2й Акт (из 2) Могут быть внешними специалистами


Слайд 20

21 Внедрение ПО. КАК? Карта проектных работ (в принципе, от продукта не зависит) Собранные в процессе проекта BSC Требования к ПО для BSC (выход 1го акта) Проектирование и согласование решений Подготовка-Тестирование ПО / Обучение ЗАПУСК Сбор требований Проектные окружения Бизнес- специалисты Промышленное окружение Данные для конвертации Сценарий тестирования процесса Ряд критичных показателей, показывающих,что именно Заказчики проекта ждут от внедрения? Должны проистекать из Инициатив. Пишет ФА, опираясь на требования Владельцев Процессов и Инициативы Общая схема программного комплекса с отображением всех потоков данных, оценкой их объема, какие бизнес-функции обслуживает каждое ПО, общая структура учетных аналитик, прочие глобальные требования – функциональная валюта, базовые единицы измерения, шкала периодов и пр. Пишет ФА, опираясь на Инициативы и требования Владельцев Процессов Техническая схема программного комплекса с отображением всех серверов, программных продуктов, областей хранения данных, сетевой инфраструктуры, механизмов бэкапов и прочего оборудования, необходимого для реализации Функциональной Архитектуры. Пишет ТА, опираясь на Инициативы и требования ФА Описание, каким образом и с какой детальностью нужно загрузить информацию о прошлых периодах из прежних систем, чтобы она сложилась в целостную учетную картину в новых системах. Пишет ФА, опираясь на Инициативы и требования Владельцев Процессов Проектная группа может оценить производительность системы только на точечных операциях. Чтобы понять, выдержит ли система реальную многопользовательскую нагрузку, нужно определить ряд узких мест и автоматизировать для них тестирование производительности Пишут ФА и ТА, опираясь на Инициативы и требования Владельцев Процессов Исходя из Стратегии Конвертации формируется список Объектов, которые нужно загрузить (сконвертировать) из старых данных в новые (незакрытые счета, остатки, клиенты, и т.п.). Для каждого объекта определяется метод загрузки – вручную (если немного), или стандартный механизм загрузки (если есть), или механизм, который нужно разработать (если много и стандартного нет) Пишут ФА и ПО-специалисты, опираясь на Инициативы и требования Владельцев Процессов Технические процессы – это фрагменты бизнес-процессов, которые требуют своего выполнения в системе. Заведение счета, резервирование дебиторки, амортизация ОС, etc. Впрочем, на уровне входящих-исходящих событий в тех.процессах прописывается связь с бизнесом – в каких именно ситуациях каждый процесс нужен и на что его результат влияет дальше. Каждый процесс – это последовательность шагов, выполняемых в системах или вручную. Пишут ФА и ПО-специалисты, опираясь на Инициативы и требования Владельцев Процессов Поток – это цепь, в которую можно объединить несколько технических процессов, состыковав их по входящим-исходящим событиям. Каждая цепь обозначает непрерывную эстафету видоизменяемых внутри ПО данных. Разрыв в цепи означает невозможность двигаться дальше (например, нельзя принятыми деньгами закрыть дебиторку, если она не отражена в системе). Входы и выходы таких цепей должны быть самодостаточны. Например – «Клиент пришел и просит билет». Если какие-либо процессы висят в воздухе, или внутри цепей есть нестыкуемые пробелы – это повод доработать списки и границы процессов. Пишут ФА и ПО-специалисты, опираясь на Инициативы и требования Владельцев Процессов На базе сценария тестирования процесса нужно создать инструкцию выполнения процесса для пользователей. Пишут ПО-специалисты Тестирование отдельных расширений и отдельных процессов – проверка работоспособности выбранных решений как таковых. Используются «спотолочные» данные. Тестируют ПО-специалисты и разработчики Тестирование отдельных процессов с установленными расширениями уже на имеющих бизнес-смысл данных – анализ правильности выбранных решений с точки зрения бизнеса. Тестирование Конвертации. Тестируют ПО-специалисты с бизнес-специалистами Тестирование потоков с установленными расширениями уже на имеющих бизнес-смысл данных – анализ совместимости всех выбранных решений и правильности работы системы в целом с точки зрения бизнеса. Тестирование стратегии Конвертации в целом. Тестируют бизнес-специалисты при помощи ПО-специалистов Прогон отлаженных потоков руками будущих пользователей на имеющих бизнес-смысл (или реальных из прошлых периодов) данных. Самая эффективная форма обучения. Проверка корректности инструкций пользователей. Проводят бизнес-специалисты при помощи ПО-специалистов Загрузки данных ручным вводом или интерфейсами, требующими только настройки и подготовки загрузочного файла. Пишут ПО-специалисты Загрузки данных интерфейсами, которые еще нужно разработать. Все эмуляторы нагрузочных тестирований Пишут ПО-специалисты Шаги процессов, осуществление в системе которых требует механизмов, которые еще нужно разработать. Пишут ПО-специалисты Шаги процессов, осуществление которых в системе требует только настройки. Пишут ПО-специалисты ПО-специалисты при участии Бизнес-специалистов Сотрудники Центра Поддержки, обучаемые ПО-специалистами Разработчики Сотрудники Центра Поддержки, обучаемые ПО-специалистами По каждому шагу процесса делается вывод – реализуем ли он в системе стандартными средствами? Если НЕТ, нужно написать ТЗ на разработку расширения – дополнительной функциональности, выполняемой программистом проекта и встраиваемой в ПО. На каждую разработку формируется отдельный документ. Конвертация через интерфейс загрузки рассматривается как отдельная разработка. Как и эмулятор ввода или обработки большого объема данных для нагрузочного тестирования. Пишут ПО-специалисты опираясь на Инициативы и требования бизнес-специалистов По каждому шагу процесса делается вывод – реализуем ли он в системе стандартными средствами? Если ДА, нужно разработать и задокументировать, какие настройки нужно осуществить в системах для успешного выполнения данного шага. На каждый процесс формируется отдельный документ. Конвертация вручную рассматривается как процесс ввода данных. Пишут ПО-специалисты опираясь на Инициативы и требования бизнес-специалистов Функциональная часть документа описывает, для каких именно бизнес-требований нужно настроить в системе данные свойства. Пишут ПО-специалисты опираясь на Инициативы и требования бизнес-специалистов. Техническая часть документа описывает, какие именно действия нужно осуществить в системе для реализации данных настроек. Пишут ПО-специалисты опираясь на свое знание ПО Сценарий тестирования процесса описывает необходимую последовательность действий и ожидаемые результаты, которые подтвердят правильность настроек, и правильность разработок для шагов процессов, не реализуемых стандартными средствами. Пишут ПО-специалисты опираясь на требования бизнес-специалистов. Функциональная часть документа описывает, для каких именно бизнес-требований нужно выполнить данную разработку. Пишут ПО-специалисты опираясь на Инициативы и требования бизнес-специалистов. Техническая часть документа описывает алгоритм работы расширения (какие операции и скакими данными выполняются, формы вывода отчетов и т.п.) Пишут ПО-специалисты опираясь на свое знание ПО Сценарий тестирования расширения описывает необходимую последовательность действий и ожидаемые результаты, которые подтвердят правильность разработки. Пишут ПО-специалисты опираясь на требования бизнес-специалистов. При разработке процесса нужно сразу определять, кто его будет выполнять, и какие уровни доступа и настройки будут нужны каждому логину. Пишут ПО-специалисты опираясь на требования бизнес-специалистов. Сценарии тестирования потоков – это «склеенные» сценарии тестирования процессов, объединенные общей бизнес-ситуацией (например, в одном процессе дебиторка создается, в другом создается оплата, в третьем дебиторка закрывается оплатой в ноль. Чтобы «склеить» это в поток, нужно создавать и счет и оплату на одного и того же клиента и оплата должна быть равна дебиторке). Пишут ПО-специалисты опираясь на требования бизнес-специалистов. В процессе написания ТЗ на настройку и ТЗ на разработку могут возникать взаимные требования, которые нужно фиксировать как закрытые вопросы, адресованные к автору второго документа (например, не выполнять такое-то действие в таком-то расширении, если в таком-то шаге процесса не заполнен такой-то параметр) Программное Обеспечение ВНЕДРЕНО CEO ОТДАЛ ПРИКАЗ О НАЧАЛЕ РАБОТЫ ПО НОВЫМ ПРОЦЕДУРАМ С ИСПОЛЬЗОВАНИЕМ НОВОГО ПО ! 2й Акт (из 2) Возможны несколько итераций до тех пор, пока не станет ВСЕ OK


Слайд 21

22 ЭПИЛОГ. Зачем эти знания? Итак, мы с вами проделали-таки тот самый путь ОТ импульсивного желания Главы Бизнеса навести порядок у себя на фирме (ЧЕРЕЗ осознанное желание и выбор способа постановку согласованных целей определения правил мониторинга автоматизации исполнения этих правил) К организации с согласованной деятельностью, вооруженной набором инструментов согласования. Я бы рекомендовал СЕО или его окружению, ответственному за оптимизацию деятельности компании, перед очередным намерением что-нибудь улучшить вспомнить то, что было здесь схематично набросано в 2х актах, определить, на каком этапе НА САМОМ ДЕЛЕ находится ваша компания, и аккуратно начать с ближайшего следующего. И удивление от диссонанса между вложением средств и полученным эффектом будет намного меньше, чем, например, после того, как внедрить ERP вслепую, так и не определив Целей. Не стройте замков на песке. Стройте их на прочном фундаменте. И тогда их можно будет не только показать издали пацанам, но и зайти в них, и использовать как надежный защищенный и хорошо оборудованный командный пункт, столь необходимый в современных рыночных сражениях. А участники вашей проектной группы скажут – да, вот ради ЭТОГО и правда стоило работать месяцами по 14 часов в день. Поздравляю! Дошли ? И будет всем счастье.


Слайд 22

23 Благодарности и ссылки


Слайд 23

24 Это все ;-) Пишите! ? vic.erukh@gmail.com


×

HTML:





Ссылка: