Воронка продаж в проектах

 

Управление жалобами

[[https://spamanagement.su/manager/client-oriented/372-customer-complaints]]
Выяснение ситуации, понимание причин появления жалобы

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

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

Затем нужно определить обоснована ли претензия.

В случае, когда вины сотрудника или компании в возникшей проблеме нет, нужно понимать, что жалоба – это запрос к общению.
Не бросайте клиента со своей проблемой, постарайтесь предложить ему выход из данной ситуации. Будьте вежливы и доброжелательны.

Если претензия обоснована – сформируйте ответ для клиента.

Основной алгоритм по работе с жалобами клиентов

Предлагаем работаем с жалобами клиентов следуя данному алгоритму:

принимаем претензию;
даем первичный ответ;
если его недостаточно для решения вопроса – регистрируем поступившее обращение;
выясняем ситуацию;
формируем ответ клиенту;
отвечаем на жалобу клиента;

формируем план корректирующих действий. 

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

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

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

Не следует также забывать обращать внимание на то, насколько оперативно были устранены проблемы.

Пример правил эскалации:

 Эскалация – это «подъем наверх» конфликта или проблемы, которые вы не можете разрешить самостоятельно в рамках своей роли или своих полномочий

Пример правил эскалации:

1 Попробовать договориться без эскалации.
2 Если не удалось – честно предупредить, что раз мы не договорились – я вынуждена эскалировать вопрос на такого-то менеджера, потому что интересы проекта и все такое. После этого чудесным образом в половине случаев договориться удается.
3 Продумать внятную аргументацию с позиции влияния поднимаемого вопроса на проект и на его результаты/сроки/бюджет и другие ограничения.
4 Включить в письмо (поставить в копию) или позвать на встречу с руководителем вторую сторону конфликта, чтобы решать вопрос совместно. В случае если вопрос критически важен для проекта – не забыть включить в процесс спонсора проекта, заранее согласовав с ним свою позицию.

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

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

Часто руководители проектов боятся самого слова «эскалация», почему-то считая, что в случае, если они вынесут проблему выше, они продемонстрируют свою некомпетентность,
неумение управлять командой и проч. А зря, пока вы не генеральный директор – 100% влияния и власти у вас все равно не будет (да и в случае с генеральным директором тоже),
а значит – ситуации, в которых понадобится эскалации, неизбежны. И лучше сделать это раньше, пока проекту не нанесен совсем уж большой урон.

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

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

Во вторую – те , кого проект напрямую не касается, но кто может на его очень ощутимо повлиять.

Стекхолдеры

1. Идентифицировать стейкхолдеров
А именно – составить список всех людей или групп людей, являющихся стейкхолдерами вашего проекта.

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

В списке указываем имя, должность, место в проекте (команда, спонсор, функциональный эксперт и проч.) и всю ту информацию, которая вам потом понадобится для управления им. Что это будет за информация – сильно зависит от окружения, например – язык, город нахождения, опыт работы в отрасли и проч.

Отношение конкретного стейкхолдера к проекту и его влияние можно оценить уже на этом этапе (после того, как список составлен) или на следующем.

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

Под отношением подразумевается текущая позиция человека относительно проекта: при -5 – он сделает все, чтобы проект не состоялся, или просто навредит при возможности (например, ему лично вы не нравитесь), при 0 – ему все равно (либо он вообще пока не знает про проект) и при +5 – готов изо всех сил помогать и поддерживать, ну или хотя бы радостно ждет результата. Если очень хочется – шкалу можно расширить до +/-10, но это сильно не поможет.

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

Agile

 Agile - итеративный подход к управлению проектами и разработке программного обеспечения*

Люди и взаимодействия важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласованных условий контракта.
Готовность к изменениям важнее первоначального плана.

Суть: вместо подразделений – круги. Они формируются под каждую задачу.
Порой стихийно: на корпоративном сайте размещают задачу и перечень специалистов, которые необходимы.
Люди сами заявляют себя в круг. Сотрудник может быть участником в нескольких командах, но только при условии, что он не загружен полностью на другом проекте.
Есть два уровня кругов. Первый – внешний, в который входят собственники и гендиректор.
Этот круг ставит задачи.
Второй уровень круга – внутренний. Это и есть команды, которые задачи решают.
Между двумя кругами есть еще менеджер-связной. Он доводит до кругов второго уровня задачи, которые ставит внешний круг.
Никакой многозадачности! Каждый круг решает только одну задачу.
Каждый участник команды, по сути, отчитывается перед коллегами.
!!

«хорошо, я вижу, почему ты так считаешь и этого желаешь; давай найдём способ действовать вместе ».
Это сознание, которое уже не может игнорировать, что вокруг есть люди, которые не нравятся, исповедуют другую веру, отличаются по ценностям, и всё же они — такие же люди.

 

Когда нужен Scrum

для решения нетривиальных проблем - предназначен Scrum

Если же люди выполняют повторяющиеся предсказуемые задачи (пусть сложные, но похожие друг на друга проекты с четкими и слабо меняющимися требованиями )
— тогда применение Scrum приведет лишь к неоправданным расходам, а вместо скрам-мастера нужен классический менеджер.

В каких проектах нужен Скрам

Задача от заказчика не содержит четких формулировок о том, каким именно должен быть ее результат, главное — польза для бизнеса .

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

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

Для успешного выполнения таких задач нужен скрам-мастер, и ему нужно делать очень многое: развивать командную ответственность, поддерживать конструктивное общение, стимулировать постоянные улучшения процесса и результативности работы.

В первую очередь, надо, чтобы команда постепенно начала осознавать свою коллективную ответственность за результат

Вся статья: [[https://scrumtrek.ru/blog/agile-scrum/5108/kto-takoi-scrum-master-i-zachem-on-nuzhen-komande/]]

Редактировать эту секцию

*Чтобы команда повышала свою эффективность (т.е. качество и/или скорость работы),
необходимо регулярно анализировать прошедшие спринты, выявлять проблемы,
избавляться от неудачных элементов рабочего процесса и, наоборот, закреплять хорошие практики.¶

Как правило, люди не привыкли тратить время даже на выявление проблем своей работы.
В команде людям трудно договориться между собой: что хорошо, что плохо и что не важно, какие препятствия стоит устранять
и какие лучшие практики стоит распространять на всю команду.
А еще труднее потом выполнять эти договоренности.
Это самые сложные моменты в работе Scrum-мастера, требующие длительного времени и большого опыта.

Scrumban

 

Методики управления проектами Scrumban

В Scrumban есть лимиты на количество рабочих задач.
Этот показатель зависит от участников команды.
Например, если задействовано 7 человек, количество незавершенных процессов равно 7.

Планирование в долгосрочной перспективе
Команды Scrumban пользуются сегментами долгосрочного планирования. На практике это выглядит так: карта разбивается на 3 блока и отображается на Канбан-доске. В первой колонке указаны цели длительной перспективы — на год. Более четкие планы, которые необходимо реализовать в течение 6 месяцев внесены во второй сегмент, а наиболее срочные, на ближайшие несколько месяцев или даже недель — в третий.

Scrumban — это мастерское соединение Kanban и Scrum в одну систему, но существуют некоторые отличия от предшественников:

Разработка внедряется легче, чем в случае со Scrum, и в этом отношении гибридный метод больше напоминает Kanban. В итоге адаптироваться к новой системе проще, а значит работа уже со старта будет более эффективной и понятной.
Постоянное совершенствование. Метод бесконечно развивается и улучшается. Этот процесс обеспечивается в основном за счет внедрения элементов Scrum.
Scrumban использует систематизацию более сложной методики Scrum и визуализацию более легкого в восприятии метода Kanban. Это позволяет командам получать объединенные преимущества двух популярных подходов в управлении IT-проектами.

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

h1. Методология управления проектами Scramban

Scrumban — современный метод–гибрид, использующий непрерывный рабочий процесс из Kanban вместе с полезными элементами Scrum, позволяющий решить проблемы обоих подходов
Как получить максимум?
Если вы заняты в сфере разработки и создаете продукт, оптимальным решением для вас будет использовать фреймворк Scrum, усиленный Kanban-методом. Например:

визуализацией всех этапов разработки от Discovery (когда происходит уточнение продуктовой ценности), до Delivery (когда происходит доведение выбранных задач до готовности)
визуализацией стратегических инициатив, крупных задач, которые будут двигаться по доске, а вы будете управлять ими
ограничением одновременно выполняемой работы на этапах
внедрением системы метрик времени выполнения

Немного о различиях Scrum и Канбан

Разница в смысле встреч и способе их проведения в методологиях Scram и Kanban
Каждая встреча Scrum нацелена на одно из двух:

или на координацию движения команды (ежедневные митинги, планирование, обзор спринта),
или на развитие командного взаимодействия, опыта или навыков Scrum-команды (ретроспектива).

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

Так как основа Канбан-метода — это данные и статистика, то цель встреч заключается в том, чтобы проанализировать собранные данные о рабочем процессе,
выделить системные проблемы и принять управленческие решения способах изменения рабочего процесса ради устранения выявленных проблем.
Эти решения принимает менеджер сервиса по итогам встречи

Например, на ежедневном митинге возле Канбан-доски собираются данные о блокерах, трудностях, ожиданиях, которые препятствуют свободному движению потока задач,
и менеджер решает как перераспределить ресурсы, чтобы обеспечить завершение задач, которые ближе всего к завершению

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

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

Чтобы Scrum начал приносить пользу, нужно сделать многое, н-р:
Выделить Владельца продукта -специального представителя бизнеса;
Выделить на 100% всех необходимых специалистов в кросс-функциональную Scrum-команду;
Выделить Scrum-мастера, который будет заниматься развитием самоорганизации в Scrum-команде;
Сделать так, чтобы Scrum-команда могла поставлять результат короткими итерациями (1-4 недели);
Обучить основам работы по Scrum всех...

Чтобы Kanban-метод начал приносить пользу, достаточно обучить руководителя или менеджера Канбан-методу и сделать первые шаги:
визуализировать рабочий процесс по вашему сервису;
сделать соответствующую Kanban-доску;
разместить на ней все текущие работы;
проанализировать положение вещей и принять управленческие решения.

Все инструменты Kanban-метода можно применять при работе по Scrum:
сбор метрик, ограничение одновременно выполняемой работы (WIP-лимит), визуализация и тд.

Скрам — это не про “сделать больше задач и успеть в срок”. Здесь будет уместнее говорить про возможность создавать небольшими порциями продукт с целью получить обратную связь от пользователей
Скрам — это про работу в условиях неопределенности, когда результат плохо предсказуем.

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

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

Резюмируем:
Фреймворк Scrum стоит применять в продуктовой разработке для того, чтобы чаще и быстрее тестировать новые версии продукта и корректировать вектор на основе обратной связи. Работает в условиях неопределенности. Чтобы начать работать по Скраму нужно сначала создать кроссфункциональную команду и обеспечить ее необходимыми ролями — Владельцем продукта и Скрам мастером, а далее запустить спринты, в течение которых команда создает кусочек ценности , вы должны показать его заинтересованным лицам и протестировать на пользователях.

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

Понятие User Story

 Понятие User Story

User Story, или пользовательская история, помогает увидеть функции продукта глазами конечного потребителя. Основную часть User Story пишут кратко, без технических деталей и лишних подробностей.
Главное — сделать фокус на целях и потребностях людей. Они короткие, написаны деловым языком и поэтому понятны всем заинтересованным лицам проекта
Главное  в пользовательской истории —  это ценность, которую пользователь получит от функции

В основной части User Story обычно указывают:

● категорию, к которой относится пользователь;
● действие, которое он или она хотели бы совершить;
● результат, который ожидает получить пользователь после действия.
В историю обязательно включают критерии приёмки — условия, которые должны быть выполнены , чтобы история считалась завершённой.

1. Фокусироваться на преимуществах для пользователя.
Бывает, что в User Story описывают только функциональность системы, а о том, зачем это пользователю, забывают.
Нужно обязательно добавить результат или ценность для пользователя — обычно это часть с союзом «чтобы».
2. Создавать небольшие и выполнимые User Story.
Не стоит писать объёмные истории, которые потребуют много времени для разработки.
Лучше написать несколько небольших
3. Добавлять детали в критерии приёмки.
В пользовательской истории описание будущих функций продукта должно быть общим, без деталей дизайна и разработки, например: «Как пользователь, я хочу быстро найти кнопку на главной странице, которая позволит мне зарегистрироваться на сайте».
Все уточнения вносят в критерии приёмки во время обсуждения User Story в команде.

Стиль:
Истории пишутся в три строки:
Как Х,
Я хочу Y,
Чтобы Z.

Три С в User Story
Первое определение говорит о коммуникации и карточках, но не упоминает согласие. Эти три понятия образуют "the 3 C's of User Stories".

Card  —  по задумке автора метода истории пишутся на физических карточках. В реальности они пишутся в Jira и Confluence, поэтому мы не так ограничены в детальности.

Conversation  —  каждая стори — это множество митингов вокруг нее, которые и направлены на понимание деталей.

Confirmation  — перед началом работы клиент дает согласие на данное решение, а команда полностью уверена в выполнимости решения.

Управление требованиями

*Требование должно обладать следующими характеристиками:

Единичность — требование описывает одну и только одну вещь.

Завершенность — требование полностью определено в одном месте и вся необходимая информация присутствует.

Последовательность — требование не противоречит другим требованиям и полностью соответствует документации.

Атомарность — требование нельзя разделить на более мелкие.

Отслеживаемость — требование полностью или частично соответствует деловым нуждам как заявлено заинтересованными лицами и задокументировано.

Актуальность — требование не стало устаревшим с течением времени.

Выполнимость — требование может быть реализовано в рамках проекта.

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

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

Проверяемость — реализованность требования может быть проверена.*

В соответствии с ITILv3 все требования в проекте можно разделить на следующие группы:
Функциональные (Functional) — реализуют саму бизнес-функцию.
Управленческие (Manageability) — требования к доступным и безопасным сервисам; относятся к размещению системы, администрированию и безопасности.
Эргономические (Usability) — к удобству работы конечных пользователей.
Архитектурные (Architectural) — требования к архитектуре системы.
Взаимодействия (Interface) — к взаимосвязям между существующими приложениями и программным средствами и новым приложением.
Сервисного уровня (Service Level) — описывают поведение сервиса, качество его выходных данных и другие качественные аспекты, измеряемые заказчиком.

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

 

Сбор требований — это процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения поставленных целей.
Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения содержания продукта и проекта.
Этот процесс выполняется единожды или в предопределенные моменты в проекте .

Существуют разные методы сбора требований,:

анализ данных;
интервьюирование;
анкетирование;
работа в “полях”;
мозговой штурм;
бенчмаркинг.

1 Анализ данных Этот метод считается одним из самых трудоемких, но позволяет сформировать требования, основываясь на фактах работы системы или на основе нормативных документов .
Для бух и налогового учета , стандартных фин. отчетов этого метода почти достаточно
Для управленческого учета - нужен более комплексный сбор требований

Анализ данных может в себя включать:

изучение технической и нормативной информации;
работа с приложением/продуктом;
работа с набором данных (например отчет в excel, который необходимо автоматизировать);
работа с программным кодом.
Анализ данных позволит тебе погрузиться в задачу и начать разговаривать с бизнесом на одном языке.
Важная цель составить требования так, чтобы это не привело к нарушению существующих бизнес-процессов, поэтому важно погрузиться в предметную область, с которой работаешь.

2 Интервьюирование -один из самых эффективных методов сбора требований. Если ты провел интервью качественно, то, скорее всего, ты сможешь составить 80% требований на основе этой информации. Хоть данный метод и является в большей степени устный, не стоит пренебрегать протоколированием и согласованием результатов интервью.

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

3 Анкетирование
Данный метод сбора требований предполагает специально оформленный список вопросов, закрытого и/или открытого типа. Анкетирование полезно для того, чтобы подтвердить или детализировать существующие требования или выбрать наиболее удачный вариант реализации.

4 Работа в “полях”
имеет большое значение, когда вы не владеете предметной областью, позволяет избежать недопонимания, которое может возникнуть при проведении интервью, которое не предусматривает использование приложения/продукта бизнеса.Н-р, что менеджер по продажам рассказывает тебе, как создавать клиента, оформляет клиенту карту лояльности или оформляет доставку на заказ. В этот момент он не демонстрирует программные средства, с помощью которых он выполняет эти действия. В результате такого интервью сложно повторить процесс в системе, в которой работает менеджер по продажам и, следовательно, сложно качественно описать требования.
5 Мозговой штурм
Мозговой штурм целесообразно использовать, когда нужны новые идеи или творческие решения задач.
Любой мозговой штурм состоит из двух этапов :
генерация идей;
отбор идей.
Среднее время генерации идей составляет один час .
Правила генерации идей:

каждая идея фиксируется ведущим мозгового штурма со слов автора;
идея не обсуждается в процессе генерации идей;
мозговой штурм продолжается, пока все участники не почувствуют, что достигли логического конца/исчерпали идеи.
Отбор идей:
фильтрация идей;
группировка и уточнение идей;
расстановка приоритетов.

6 Бенчмаркинг
Бенчмаркинг (эталонное оценивание) — сопоставительный анализ на основе эталонных показателей как процесс определения, понимания и адаптации имеющихся примеров эффективного функционирования предприятия с целью улучшения собственной работы.
Анализ включает в себя два процесса:
оценивание;
сопоставление.
Обычно за образец принимают «лучшую» продукцию или и маркетинговый процесс прямых конкурентов, используемые прямыми конкурентами, работающими в подобных областях, для выявления фирмой возможных способов совершенствования её собственных продуктов и методов работы.
Ну, а если по-простому, то мы берем существующие решения, стандарты, методики и примеряем это на себя. Если после примерки выглядим хорошо и нигде не трет, а результативность наша выросла, то надо брать.
Этот метод позволяет наиболее точно составить требования, т.к. все уже реализовано, а тебе остается только переиспользовать имеющиеся наработки, с учетом собственных бизнес-процессов, нормативных документов и пожеланий бизнеса.