Бизнес роль функциональная роль

«Что наша жизнь? Игра!». А в любой игре, как известно, есть роли, если они сыграны хорошо, то игра получается удачной.
Так и хороший бизнес, бизнес будущего, должен быть игрой, театром, где каждый играет свою роль и где режиссером является клиент. При этом люди, занятые в бизнесе, могут пробовать разные роли.

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

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

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

Бизнес-разбор на тему Роли в бизнесе | Евгения Павловская

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

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

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

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

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

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

Расчет персонала в бизнес-ролях. Сопоставление бизнес-ролей и должностей. Что это дает?

Высвобождение энергии

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

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

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

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

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

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

Кто-то может со скепсисом отнестись к ролевой концепции, сказав, что «это какая-то игрушка, ерунда, у нас это не приживется…».

Но какая тогда остается альтернатива?

Это стандартная, консервативная схема неизменяемых должностей, обязанностей, система взаимоотношений в стиле «хозяин — раб», в которой нет ролей, а есть только обязательства. «Мне не важно, в какой ты роли, ты обязан завтра сдать макет, я твой хозяин, я так хочу. Не сдашь – пошел вон!»

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

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

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

Что такое ключевая роль?

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

Почему встречи происходят именно в таком стиле? Потому что каждый делает, что хочет, отсутствует элементарная культура коммуникации.

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

Фасилитатор следит за процессом, он говорит, что делают люди, когда они начинают говорить, когда заканчивают. Скрайбер записывает все результаты процесса, всё то важное, что было сказано. Коуч пытается распознать какие-то личностные, межличностные зоны роста. Участник встречи – это тоже роль и у него есть свои права.

Ключевых ролей может быть только фиксированное число.

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

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

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

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

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

Необходимо также сказать о ролях — аватарах.

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

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

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

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

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

Если вдуматься, ролевая функция пронизывает всё существо мира. Так, например, в организме у каждого органа есть роли, в природе у каждого животного есть своя роль. У каждого цвета есть своя роль

И все эти роли непрерывно живут и играют друг с другом.

Поняв принцип работы ролей, далее можно выполнять задания, например:

· создавать роли в круге

· понимать, какие роли хорошие, а какие плохие

· учиться проявлять аватар

· договариваться между разными ролями

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

· выбирать предназначение для роли, разбираться, может ли роль существовать без предназначения или нет

· понимать, как создается роль, в какой момент надо ее создать.

· решать конфликты между людьми через роли

· разбираться, чем отличаются ключевые роли от функциональных, можно ли отменять ключевые роли

· понимать, можно ли изменять ключевые роли, функциональные роли или они устанавливаются навсегда

· понимать, насколько часто можно изменять роли

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

Дело за малым – попробовать и начать «жить, припеваючи»!

Источник: dzen.ru

Бизнес роль функциональная роль

Введение

Проект внедрения ERP-систем подразумевает не только конфигурирование коробочного решения, но и его доработку. Согласно [1], настройка системы позволяет покрыть не более 30% бизнес потребностей предприятия, оставшиеся 70% требуют программных доработок решения. Приблизительное число требований в проекте внедрения ERP-системы для автоматизации логистических, финансовых и кадровых бизнес-прессов около 300. Следуя статистическим данным, в ходе проекта необходимо будет реализовать порядка 200 программных разработок. Полученная цифра выглядит достаточно убедительно и накладывает особые требования по обеспечению качества реализуемых приложений.

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

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

Цель и задачи

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

• рассмотрение структуры технических ролей;
• обзор принципов формирования бизнес-ролей;
• подготовка матрицы доступа в ERP-системах;
• формирование стратегии ролей и полномочий.

1. Логика работы программы

Рассмотрим логику работы любой программы, чтобы понять аспекты конфигурирования ролей и полномочий. Следуя работе [2], каждая программная разработка представима тремя экранами: селекционный, выбранных и обработанных данных. Селекционный экран позволяет указать входные данные для работы приложения, экран выбранных данных отображает информацию, изъятую из таблиц баз данных с использованием ограничений селекционного экрана, и, наконец, экран обработанных данных содержит обновленную информацию, если пользователь выполнил операцию добавления, изменения или удаления над записями предыдущего экрана. Для ролей и полномочий важна следующая парадигма:

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

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

Технические роли обычно ведутся в разрезе функциональных областей ERP-системы. Минимальное число программ, доступ к которым может быть выдан пользователю, задает количество программ в одной техроли. Если рассмотреть ERP-систему на примере SAP ERP, то в ней выполняется настройка отдельных технических ролей, каждая из которых содержит перечень доступных для запуска программ, набор данных, определяющий допустимые организационные уровни программ, а также объекты полномочий, задающие возможные операции над данными программ, такие как: просмотр, создание, изменение, архивирование и др.

Рис. 1. Логическая схема ролей

Бизнес-роль содержит в себе несколько технических ролей из разных функциональных областей [3]. Именно бизнес-роль роль в последующим присваивается конечному пользователю в ERP-системе. Возникает вопрос, по какому принципу включить техроли в бизнес-роль. Здесь существует два подхода.

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

2. Матрица доступа

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

Рис. 2. Матрица доступа

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

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

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

Литература

1. Калянов Г.Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. – М.: Горячая линия – Телеком, 2014. – 210 с.
2. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268. – URL: https://stepanovd.com/science/26-article-2014-4-design.
3. Степанов Д.Ю. Анализ, проектирование и разработка корпоративных информационных систем: уровень приложений / МГТУ МИРЭА. — М., 2017. – URL: https://stepanovd.com/science/12-erp/52-erp-8-applicationlevel.

Выходные данные статьи

Петров С.В. Стратегия ролей и полномочий в ERP-проектах // Корпоративные информационные системы. – 2018. – №3 (3) – С. 53-58. – URL: https://corpinfosys.ru/archive/issue-3/143-2018-3-authorizationstrategy.

Об авторе

Статьи выпуска №3

1. Разработка проекта системы управления цепями поставок (часть 1);
2. Стратегия тестирования в проектах имплементации ERP-систем;
3. Управление ожиданиями в проектах имплементации ERP-систем;
4. Стратегия ролей и полномочий в ERP-проектах;
5. Стратегия обучения пользователей в проектах внедрения ERP-систем.

Источник: corpinfosys.ru

Бизнес роль функциональная роль

Отрывок из книги Е. Михайленко Архитектура высокоэффективного бизнеса. Как перестать быть заложником обстоятельств и заставить бизнес работать на себя.

Функциональные роли участников бизнес-процессов

В каждом бизнес-процессе можно выделить основные функциональные роли участников:

• Заказчик (тот, кто заинтересован в непосредственном бизнес-процессе);
• Архитектор (тот, кто создает схему бизнес-процесса);
• Оперативный менеджер (тот, кто руководит осуществлением бизнес-процесса);
• Исполнитель (тот, кто непосредственно исполняет тот или иной этап бизнес-процесса).

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

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

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

Очень скоро они зададут себе вопрос: а зачем им вообще нужны Вы и кто Вы вообще такой… Вертикальное совмещение функциональных ролей недопустимо! Если функциональные роли совмещены вертикально по важным бизнес-процессам, Вы неизбежно потеряете бизнес.

Даже если работники будут Вам исключительно лояльны (что бывает не всегда), никогда не исключайте вероятности того, что Вы можете потерять сотрудника по независящим от него причинам, а при такой ситуации Вы потеряете и весь бизнес. Если же такая ситуация складывается по неважным бизнес-процессам Вы рискуете стать объектом шантажа со стороны таких работников. Замыкание функций по горизонтали расширяет опасности, а замыкание по вертикали усиливает опасности. И еще раз, бизнес-процессы, замкнутые на одного человека по вертикали, Вы никак не можете контролировать!

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

Роль Бухгалтерия IT Безопасность Производство
Заказчик Х
Архитектор Х
Оперативный менеджер Х
Исполнитель Х

Замыкание же по горизонтали выглядит так:
Подразделение

Роль Бухгалтерия IT Безопасность Производство
Заказчик
Архитектор
Оперативный менеджер Х Х Х Х
Исполнитель

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

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

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

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

История неоднократно доказывала на практике верность данного постулата. Великая империя Александра Македонского начала разваливаться сразу же после его смерти.

Конструкторское бюро Алексеева (разработчика катеров на подводных крыльях и экранопланов) рухнуло сразу с его уходом. Доведенные до отчаяния фанатизмом Алексеева сотрудники КБ просто сразу же разбежались, кто куда смог.

После смерти Стива Джобса корпорация Apple понесла серьезнейшие финансовые потери.

Список примеров бесконечен.

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

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

Завершение бизнес-процесса

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

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

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

Постоянное совершенствование и адаптация сами по себе являются исключительно важнейшими бизнес-процессами. Если в этом направлении Вам не о чем думать, то вероятнее всего не «не о чем», а нечем…

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

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

Источник: mihico.ru