1. Цель
1.1. сделать так, чтобы заказчики продолжали хотеть то, что хотят сейчас и начали хотеть нового.
1.2. Измеритель успеха - размер бизнеса. Min не уменьшается, max растет
2. Для достижения цели нужно разработать и выполнить комплекс мероприятий, чтобы
2.1. приобрести и выявить конкурентные преимущества
2.2. выработать механизмы развития уровня качества
2.3. выработать механизмы распространения на новых заказчиков
3. Определяем где у management есть систематически слабые места
4. 1. Удовлетворенность нужд заказчика и управление им. Основополагающее направление, остальные вспомогательные
4.1. Проблемы
4.1.1. не знаем решаем ли истинную задачу заказчика
4.1.2. не знаем какую задачу заказчика решаем
4.1.3. не знаем какие еще проблемы\задачи можно решать
4.1.4. не всегда знаем кто ЛПР и какую задачу он решает
4.1.5. мы сами не привыкли думать в терминах "частью решения какой проблемы заказчика мы являемся"
4.2. AI
4.2.1. Маляев А.: Провести аудит на тему «какие задачи/проблемы решаем для текущих заказчиков».
4.2.1.1. На этом этапе не используем заранее подготовленной классификациии задач/проблем. Важно получить «сырые» данные.
4.2.1.2. Важно указывать признаки и доказательства, почему считаем, что имеем дело именно с указанной задачей/проблемой.
4.2.1.3. Индуктивный метод. Как собрать эту информацию с заказчика?
4.2.1.3.1. Tet-a-tet разговор. Прямой вопрос "Почему вы сотрудничаете с мерой?"
4.2.1.3.2. Напрямую спрашивать не надо! Такого списка вопросов заранее создать нельзя.
4.2.1.3.3. Добавить пункт в CSAT опросник: "В какой области еще хотели бы сотрудничать с Мерой"
4.2.1.3.4. Постоянный онсайт менеджер (для больших заказчиков)
4.2.1.3.5. Анализ открытых источников (новости, вакансии и пр.)
4.2.1.3.6. Онсайтная программа для ACD/PRM/PM
4.2.1.4. Дедуктивный метод. Можно ли собрать достоверную информацию от PRM/ACD?
4.2.1.4.1. Признаки достоверности информации
4.2.1.4.2. Признаки недостоверности.
4.3. Решения \ предложения
4.3.1. Сформировать классификацию типов заказчиков и типов задач\проблем, с которыми они приходят к нам.
4.3.1.1. по "сферическим коням" отдельная активность - Комардин И.
4.3.2. когда поймем классификацию, понять правильно ли решаем задачи и как улучшить пути решения
4.3.3. определить наши ключевые преимущества, чтобы решать задачи заказчика за бОльшие деньги
5. 2. Фактическое качество сервисов. Баги, KPI, SLA
5.1. Проблемы
5.1.1. текущие меры контроля фактического качества не кажутся достаточными
5.1.2. Quality dept. работает при прочих равных. Обращает внимание только на процессную составляющую (процессы внедрены и считаем, что они как минимум не ухудшают ситуацию.
5.1.3. квалификация персонала не нормируется процессами
5.1.3.1. технические навыки
5.1.3.2. английский язык
5.1.3.3. материальное обеспечение
5.1.3.4. внешние обстоятельства
5.1.4. обучение - нет маппинга экспертизы, сквозного код. ревью
5.1.5. как понять плохо или хорошо? становится хуже или лучше (динамика процесса)? как измерить?
5.1.5.1. CSAT, не работает?
5.1.5.2. KPI
5.1.5.3. косвенные признаки
5.2. AI
5.2.1. Петров Д.: Составить список показателей, которыми можно определить/измерить фактическое качество наших сервисов.
5.2.1.1. Это нужно, чтобы потом понять чем управляем, а что на самотек и достаточны ли текущие меры для поддержания фактического качества сервисов.
5.2.1.2. Должны входить не только стандартные метрики (a-la TL9000), но и другие показатели, влияющие на фактическое качество сервисов (например уровень владения английским языком).
5.3. Решения \ предложения
5.3.1. нужно понять достаточные ли текущие меры контроля за фактическим качеством
5.3.2. выявить чем управляем сейчас, а что пущено на самотек
6. 3. Процесс управление качеством и удовлетворенностью заказчика. Механика дела - чеклисты, роли, процедуры, накопление и использование опыта.
6.1. Проблемы
6.1.1. Quality team подходит к процессу формально
6.1.1.1. вера, что рамочный надзор приводит к качеству
6.1.1.2. не вникает в специфику проекта
6.1.1.3. не принимает в расчет отклонения от среднего в компетенции и мат. обеспечении
6.1.2. нужна не процессная роль, а КОМПЕТЕНТНЫЙ ЦЕНТР ПОМОЩИ
6.2. AI
6.2.1. Хорев В.: Описать цели, задачи и орг. структуру PM office
6.2.1.1. какие задачи мог бы решать PM office в рамках BU UMCA
6.2.1.2. какую орг. структуру и бюджет (ФОТ) мог бы иметь
6.3. Решения \ предложения
6.3.1. Создать PM Office (аналог CTO в разрезе процессов управления качеством и удовл. заказчика)
6.3.1.1. pros
6.3.1.1.1. вовлеченный подход, в отличие от формального в Quality team
6.3.1.1.2. централизованная база истории и знаний
6.3.1.1.3. помогает в новых проектах, инструменты, процессы
6.3.1.1.4. может помогать Quality team
6.3.1.1.5. education management включается
6.3.1.1.6. ответственность зп QSI включена по умолчанию
6.3.1.1.7. должно положительно работать в артели
6.3.1.2. cons
6.3.1.2.1. нужен бюджет, RPH
6.3.1.2.2. если участи в PMO добровольное, то эффективность низкая
6.3.1.2.3. будет хуже работать в крупных проектах (Avaya, Ascom и т.д.)
6.3.1.2.4. не дотянется до уровня инженеров
6.3.1.2.5. не будет одобрено руководством
6.3.1.3. должны контактировать с заказчиком и ACD?
6.3.2. Улучшить систему тренингов менеджеров
6.3.2.1. pros
6.3.2.1.1. небольшие бюджетные вложения
6.3.2.2. cons
6.3.2.2.1. самостоятельно люди не будут читать и применять
6.3.2.2.2. нет правил игры
6.3.2.2.3. нет накопления экспертизы
6.3.2.2.4. продолжать так, как делаем сейчас, но чуть более сфокусированно
6.3.3. бОльший список проверок при аудите - нужен фреймворк для управления качеством сервиса, чтобы не изобретать велосипед, но работать над содержательной частью
6.3.3.1. применять для новых заказчиков
6.3.3.2. проводить аудит
6.3.3.3. накопленные данные не терять
6.3.3.4. сохранить возможность повторного использования
7. 4. Компетентность и готовность менеджерского состава, как ключевого участника QSI Program. Необходимые навыки, слабые места, мотивация и методики улучшения оных
7.1. Проблемы
7.1.1. Не чувствуют ответственность за задачу от заказчика.
7.1.2. Не хватает способностей определить и исправить недостатки в процессах
7.1.3. небольшая онсайтная программа для менеджеров, разве проблема?
7.2. AI
7.2.1. Кривошеин С.: Определить области менеджерских знаний, влияющих на Service Quality и поддающихся систематическому улучшению
7.2.1.1. решаем меняем ли и как меняем
7.3. Решения \ предложения
7.3.1. Ротация менеджеров между проектами
7.3.2. ДИ - повышать категорию в зависимости от реального опыта в проектах (срок, количество)
8. 5. Компетентность и удовлетворенность персонала. Степень вовлечения персонала в QSI Program. Отчасти покрывается второй рабочей группой
8.1. Проблемы
8.1.1. Низкая вовлеченность в общее дело (чтоб по ПОХЕР)
8.1.2. Недостаток лидерства на всех уровнях организации
8.1.3. внутренний и внешний имидж компании - этому уделяется мало внимания
8.1.3.1. брендинг, ремонт
8.1.3.2. печеньки, кофе
8.1.3.3. стулья
8.1.4. имидж компании влияет на удовлетворенность заказчика
8.2. AI
8.3. Решения \ предложения
8.3.1. Доп. тренинги на уровне BU про хорошие практики программирования
8.3.2. прописать ответственность за качество в ДИ
9. 6. Ключевые преимущества МЕРЫ (почему должны выбрать Меру)
9.1. Проблемы
9.1.1. должны уметь стаффинг, но не очень умеем
9.1.2. должны уметь делать проекты, не всегда знаем как