Цифровыми продуктами называют продукты, произведенные с помощью цифровых технологий. Процесс внедрения новых технологий и цифровых продуктов во все сферы жизни и производства называют цифровизацией.
Выделяют три группы цифровых продуктов на базе особенностей их производства и потребления. Первая группа образуется продуктами, разрабатываемыми исключительно в электронном виде и не имеющими материального прообраза (например, программное обеспечение). Во вторую группу входят цифровые копии реальных продуктов, имеющих материально-вещественную форму (например, оцифрованная книга). И, наконец, третья группа состоит из цифровых образов реальных объектов. При этом основной задачей цифрового образа является обеспечение более эффективного управления объектами реального мира, а не замещение их в процессах потребления [3].
Для предприятий важнейшим аспектом цифровизации является повышение эффективности бизнес-процессов. Так, наиболее распространенным инструментом цифровизации можно считать использование Big data.
На практике доказано, что использование больших данных наиболее эффективно для следующих аспектов работы предприятий [2]:
— прогнозное моделирование в производстве и финансовой деятельности;
— сокращение расходов на сбор, хранение и обработку информации за счет использования аутсорсинговых облачных технологий;
— эффективное проектирование и модернизация бизнес-процессов с учетом всех возможных потерь;
— оптимизация транзакций с контрагентами;
— анализ маркетинговой и сбытовой информации, изменение структуры продаж с целью достижения максимального объема выручки.
Внедрение цифровых продуктов в бизнес-процессы предприятия неизбежно приводит к сопротивлению со стороны работников предприятия. Проблема тут не столько в самих цифровых продуктах, а в том, что любое изменение традиционных методов вызывает сопротивление всех, кого оно коснется, как менеджеров, так и их подчиненных. Чтобы справиться с этой проблемой, менеджменту необходимо понимать, почему люди не приемлют предлагаемых изменений.
Люди сопротивляются переменам по трем основным причинам [1]: неопределенность, ощущению потери и убеждение, что перемены не улучшат ситуацию. В первом случае все ясно. Люди часто противятся переменам просто потому, что не знают, что они принесут. Из-за угрозы неудовлетворения потребности в защищенности они, сознательно либо подсознательно, выражают свое негативное отношение к изменениям или выбирают дисфункциональные модели поведения в процессе их внедрения.
Вторая причина сопротивления переменам – ощущение, что перемены приведут к персональным потерям, т. е. к худшему удовлетворению той или иной потребности. Например, рабочие часто считают, что изменение технологии, скажем, автоматизация, приведет к увольнениям или нарушению социальных взаимоотношений. П. Лоуренс пишет: «По сути, сотрудники обычно сопротивляются не техническим переменам, а изменению социальных, человеческих взаимоотношений, которые, как правило, сопровождают любые технические нововведения». Люди могут чувствовать, что это ограничит их полномочия в принятии решений, формальную или неформальную власть, доступ к информации, автономию, сложность и интерес их задач.
Третья причина сопротивления – убеждение, что предлагаемые изменения нежелательны для организации или неправильны. Люди могут считать, что планируемые перемены не решат, а усугубят проблемы. Например, менеджеры очень часто убеждены, что проблема связана не с их функциональной областью, а с какой-то другой, так что перемены нужны не у них, а в другом подразделении.
В 2021 году красноярская консалтинговая компания «Ресурсинформ» проводила исследование по теме особенностей сопротивления изменениям при внедрении цифровых продуктов в бизнес-процессы малого бизнеса.
Проблема исследования: Нежелание старших сотрудников обучать других при внедрении цифровых продуктов в бизнес-процессы.
Гипотеза исследования: Без полноценного регламента обучения старшими сотрудниками рядовых коллег с надлежащими инструментами контроля его соблюдения эффективный результат соответствующей передачи знаний и навыков недостижим
Исследование проводилось методом опроса менеджеров 53 предприятий малого бизнеса Красноярска, Новосибирска, Иркутска и Томска.
1. Какой цифровой продукт внедряли в бизнес-процессы?
2. Все ли сотрудники были готовы к новым принципам работы при внедрении цифровых продуктов в бизнес-процессы?
3. Была ли необходимость обучать других при внедрении цифровых продуктов в бизнес-процессы?
4. Какие трудности при обучении сотрудников новым навыкам в бизнес-процессы?
5. Какие ошибки были допущены при обучении сотрудников при внедрении цифровых продуктов?
6. Что можно сделать, чтобы у сотрудников появилось желание обучать других при внедрении цифровых продуктов в бизнес-процессы?
7. Что влияет на оказание помощи в обучении других при внедрении цифровых продуктов в бизнес-процессы ?
8. В компании есть правило помощи новым сотрудникам?
9. Что бы в следующий раз нужно было сделать по-другому при внедрении бизнес-процессов?
10. Как преодолевали сопротивление сотрудников при внедрении?
В результате анализа итогов проведенного опроса были сформулированы следующие выводы:
1) У сотрудников всегда возникают трудности c приобретением необходимых навыков
2) При внедрении цифровых продуктов процесс обуславливающего обучения редко осмысливается как необходимый для заблаговременного планирования, что в конечном итоге приводит к некорректному результату обучения и непрогнозируемым срокам его завершения.
3) Вопрос мотивации для менторов (тех, кто «должен» обучать) сложный и трудно поддается унификации.
4) Надлежащие условия для обучения – значимый фактор успеха процесса обучения. Оптимальные условия – редкость, приходится соблюдать баланс возможностей, что также важный вопрос заблаговременного планирования.
5) Регламенты – головная боль большинства компаний. В компаниях как правило нет даже базового пакета регламентов по ключевым бизнес-процессам, а если есть – то выполняют они лишь ознакомительную функцию не являясь гибким и действенным инструментом надлежащей реализации этих ключевых бизнес-процессов. В такой ситуации «правила обучения» гарантированно становятся очередным внутренним декларативным инструментом.
6) Полноценный анализ внедрения значимых бизнес-процессов на основе цифровых продуктов не проводится в большинстве компаний. Соответственно, нет системной работы по совершенствованию подходов к внедрению последующих бизнес-процессов.
7) Стандартный набор стимулов и мотиваций для «жертв» внедрения обновленных бизнес-процессов не работает. Сама по себе эта сфера – эффективное стимулирование – является сложной областью, в которой эффективные решения находятся на стыке игровых подходов и «строгих» побуждений к дисциплине со стороны высшего руководства.
Результаты исследования указывают на вполне очевидный вывод о том, что внедрение цифровых продуктов в бизнес-процессы не может быть эффективным без применения мер по управлению сопротивлениям переменам.
В научной литературе описаны некоторые методы управления сопротивлением переменам в организациях. Каждая тактика имеет свои слабые и сильные стороны, и менеджерам важно уметь точно оценивать ситуацию и выбирать наиболее подходящий метод.
Нельзя не отметить, что адекватная оценка ситуации в организации для выбора наиболее подходящих методов управления сопротивлением переменам в организациях, сама по себе является сложной задачей, требующей творческого подхода и большого опыта управления человеческими коллективами.
Таким образом, можно заключить, что забота о подчиненных при внедрении цифровых продуктов в бизнес-процессы, выступает не только элементом развитой управленческой культуры, но выступает важной предпосылкой к результативности и эффективности внедрения изменений в бизнес-процессы предприятия.
1. Альберт М., Мескон М., Хедоури Ф. Основы менеджмента. – Litres, 2021.
2. Исайченкова В. В., Новикова А. В. Цифровизация как инструмент повышения эффективности бизнес-процессов // Modern economy success. – 2019. – №. 3. – С. 141-144.
3. Рыбачук М. А. Фенотип продуктов цифровой экономики: анализ с позиции системной экономической теории //Журнал экономической теории. – 2020. – Т. 17. – №. 1. – С. 164-175.
Источник: mcoip.ru
Стоит ли использовать продуктовый подход, если нет продукта?
В последние годы стало очень модно противопоставлять проектному подходу продуктовый. Мол, проекты — это когда зафиксированы результаты, сроки, бюджеты, и потому всё жёстко и неудобно, а продукты — это когда ничего на старте непонятно, но будем стараться создавать ценность по мере движения вперёд. Управление проектами теперь не в фаворе, управление продуктами — наоборот.
Однако многие, кто заменяет (у себя или у клиента) проектный менеджмент на продуктовый, не утруждают себя анализом границ применимости, а «приклеивают» управление продуктами и к месту, и не к месту. Приведу примеры, связанный с информационными технологиями: предположим, у нас есть идея какой-то ИТ-системы, закрывающей очень существенную потребность определённой аудитории или устраняющей очень неприятную «боль», при этом аудитория является внешней по отношению к нашей организации и, как нам кажется, готовой платить за закрытие потребности и устранение боли.
Мы до конца не понимаем, что за ИТ-система получится, как именно она будет закрывать и устранять, куда она будет развиваться, как её позиционировать, как монетизировать. На верхнем уровне идея нам ясна, а в реализации, понятное дело, будет миллион вопросов и миллиард вариантов. Пригодился бы в таком случае продуктовый подход, применённый к разработке ИТ-системы? Очень вероятно.
Теперь посмотрим на другую ИТ-систему: почти готовую, сторонней разработки, нами приобретённую и теперь кастомизируемую для автоматизации внутренних бизнес-процессов нашей компании. Да, здесь тоже есть разработка и развитие, и даже немножко неопределённости. Стоит ли в этом случае применять продуктовый подход? Совсем не очевидно, ведь продукта как такового у нас нет.
Однако очень многие зачем-то пытаются играть в продуктовый менеджмент и в таких вот кейсах. Попробуем разобраться, разумно ли это.
Определение
Сначала нам потребуется дать определение продуктовому подходу. Как это часто бывает (см. IT Service Management, Agile, DevOps, Kanban и проч.), найти годное, разумное и универсальное определение будет нелегко. Так уж повелось, что в области менеджмента используются концепции, которые мало кто пытается определить; вместо этого разные авторы и эксперты делают вид, что определения не нужны, либо что всем и так всё понятно, либо определяют через примеры (то есть: никак не определяют). Для целей настоящей заметки нам будет достаточно вот такого определения:
Продуктовый подход — это способ максимизации бизнес-результатов в условиях динамически появляющихся и меняющихся возможностей и, как правило, высокой неопределённости через определение продукта и организацию деятельности вокруг этого продукта.
При этом продуктовый подход помогает постоянно находить ответы на следующие вопросы:
- Какую бизнес-модель использовать, как её изменять? Как монетизировать?
- На какую целевую аудиторию направлять продукт? Как позиционировать и менять позиционирование продукта?
- Какую функциональность нужно добавить или изменить? Какие свойства продукта нужно создать или изменить? Когда это лучше всего сделать?
- Какую функциональность не нужно добавлять или изменять? Какие свойства не нужно создавать или изменять?
- …
Из определения и списка вопросов следует, что продуктовый подход не является универсальным.
Критерии применимости продуктового подхода
Можно выделить следующие три основных критерия его применимости:
- динамически появляющиеся и меняющиеся возможности;
- активное и постоянное развитие;
- (возможно) высокая неопределённость.
Вернёмся к двум примерам, которые я приводил в начале заметки. Для первой ИТ-системы (той, что направлена на внешних клиентов) перечисленные критерии полностью применимы. Для второй (которая направлена на внутренних клиентов) — скорее нет, чем да; возможно, сработает лишь один критерий из трёх, активное и постоянное развитие.
Продолжим рассуждения
Что происходит сразу же, как только какая-либо организация начинает «внедрять» продуктовый подход? Известно что: нужно что-то назвать продуктом и назначить владельца продукта (product owner). Некоторые ещё приглашают консультантов из большой четвёрки, тройки или кто там сейчас в лидерах — дорого, заумно, престижно.
Снова вернёмся к нашим примерам. В первом из них выделение продукта пройдёт, скорее всего, просто и безболезненно — все, кому нужно, будут достаточно хорошо представлять себе что именно мы понимаем под данным продуктом. Равно как и назначение владельца продукта будет означать, что у данного персонажа появляются значимые в рамках организации ответственность и полномочия, зачастую сильно завязанные на P
Продукт как инструмент бизнеса
Зум Углёва Светлана, продукт как инструмент для бизнеса
Скажу так: не видел, чтобы перечисленные элементы приносили вред, зато видел, как они приносят пользу, даже если настоящих, «взрослых» продуктов нет.
И второе: в большой организации (читай: Enterprise) от унификации подхода может быть больше пользы, чем вреда, если, конечно же, всё стараться делать с умом. Что я имею ввиду: несколько лет назад активно обсуждалась концепция бимодальных ИТ, или мультискоростных ИТ (название зависит от того, чьи материалы вы читаете, Gartner или Forrester).
Предполагалось, что в одном и том же ИТ-департаменте часть систем могут развиваться и использоваться (change https://cleverics.ru/digital/2022/03/product-management-without-products/» target=»_blank»]cleverics.ru[/mask_link]
О продуктоводстве
Привет! Я Антон Жиянов, техлид в dadata.ru. Разрабатываю опенсорс, веду курсы, пишу про Python, SQL, открытые данные и облачные сервисы (много всего).
Пара слов о «Дадате», чтобы задать контекст. Облачный B2B, основное использование — через API, маленькая распределённая команда, несколько десятков тысяч пользователей.
Ничего не буду писать о метриках, гроус-хакинге, касдеве, эджайле, митапах и других традиционных развлечениях продактов. Во-первых, вы это лучше меня знаете. Во-вторых, мне интереснее говорить о другом:
Дисклеймер: я часто пишу резко и категорично. Если вдруг вы не согласны — вы правы, а я нет. Не принимайте близко к сердцу, не теряйте чувство юмора.
Продукт и фичи
У меня скорее смешанное отношение к новым фичам. Конечно, люблю бизнес-фичи, которые увеличивают прибыль и охват. Они такие вкусные, ммм.
Легко и приятно делать всякую мелкую полезную фигню. Доработать слегка демку, сделать понятнее что-нибудь в личном кабинете, добавить красивую страницу для ошибки.
Радостно уменьшать хаос и увеличивать порядок в продукте. Упорядочить документацию, сделать нормальное сравнение тарифов, поменять формулировки в интерфейсе, которые всех путают.
Весело пилить performance-фичи. Тут достаточно намекнуть разработчику и подождать, пока он всё отлично сделает. А потом ходишь надутый от гордости и всем рассказываешь, как МЫ увеличили скорость в два раза. Разве не ради этого мы стали продактами, друзья?
Скучновато делать всякие вспомогательные штуки, хотя понятно, что без них никуда. Поменять тарифные правила, переколбасить в очередной раз промо-страницы, доработать интеграцию с платёжной системой.
Категорически не годится брать в работу непрофильную муть, которая размывает фокус продукта. «Мы же обрабатываем адреса для интернет-магазинов, так давайте заодно агрегатор доставки сделаем». Ну уж нет.
Но ничто не сравнится с удовольствием УНИЧТОЖАТЬ старые фичи. Например, у нас была регистрация через соцсети с дополнительным экраном в конце. С каким удовольствием я его выпилил!
Собирательство фич
Типичная проблема продакта: начали делать фичу, она не зашла, а бросить жалко (и «а вдруг взлетит»). Так и тащат за собой недостроенную звезду смерти.
«Собирательству» фич подвержены даже лучшие из нас. Первые версии iOS были логичными и выверенными до мелочей. Сейчас айось — это какой-то безумный игровой автомат: куда не ткни случайно, отовсюду что-то выезжает и выскакивает.
Другая западня — добавить фичу, потому что потенциальный клиент говорит «добавьте, и тогда я куплю». Ага, конечно. Я вообще считаю, что к мнению неплатящих пользователей стоит относиться ооочень скептически.
Спецификации
Поскольку люди в отрасли не могут жить спокойно, каждые три года они придумывают новую концепцию. Персоны, юзкейсы, юзер стори, джоб стори, CJM, whatever. Всё это лирика.
Реально важно одно:
Для каждой фичи или сценария понимать, кто потребитель и зачем это ему.
Кто и зачем — это важно. Конкретная методика — карго-культ.
Бодрость и свежий взгляд
Главная проблема «долгоживущих» продакт-менеджеров и вообще любых сотрудников: со временем у человека замыливается глаз. Команда перестаёт видеть очевидные извне проблемы продукта и упускает возможности.
Знаю один сервис, где нельзя зарегистрировать двух пользователей с одинаковым именем (то есть не может быть две «Анны», например). Основатель мне на полном серьёзе объяснял, что это фича и так и должно быть.
Хотя со стороны очевидно, что это полная дичь.
Поэтому, если вы только пришли в проект, самое время вскрывать нелепые «багофичи», пока у вас свежий взгляд. Выписывайте всё, что кажется странным. Расспрашивайте коллег о причинах. Думайте, как достичь цели по-человечески, без костылей.
А если вы на проекте давно, то не отметайте с ходу «глупые» вопросы новичков. Лучше задумайтесь — вдруг люди «снаружи» считают вашу фичу глупым багом?
B2B и кровавый энтерпрайз
Делать продукты для бизнеса одно удовольствие! Люди настолько привыкли к плохим продуктам и плохому сервису, что когда вы делаете хорошо — работает как вау-фактор.
B2C в этом смысле труднее, потому что там у людей завышенные ожидания. А в B2B — наоборот, заниженные. Хотя и в B2C плохих продуктов хватает. Особенно плохо с саппортом — обычно он предельно механистичный и бездушный, и чем крупнее сервис, тем хуже.
В B2B сложнее, что логика продукта сильно более навороченная. Не получится взять три простых юзкейса, зато «вылизать» их до идеала.
B2B тоже бывает очень разный. Есть low-touch sales, когда сайт продаёт сам, без сейлов, только за счёт маркетинга. Это достаточно похоже на B2C, «Дадата» именно так работает.
А есть high-touch aka «кровавый энтерпрайз», где отдельные продавцы, выездные демонстрации, пресейлы, пилотные проекты и вот это всё. Это уже совсем другая история, сильно отличная от B2C.
Счета и акты
Самое «весёлое» в российском B2B — это документооборот, так же известный как «счета и акты». Если вы прискакали из мира мобилок на розовом пони, эта штука срежет вас как наточенный серп.
Бухгалтеры через одного не умеют платить без счёта (хотя вообще-то прекрасно можно жить без него). Сначала мы пытались бороться и объяснять, потом плюнули и сделали волшебную страничку.
С актами сложнее, поэтому мы честно печатали их каждый квартал, подписывали и рассылали по почте. Но с сотнями клиентов это превратилось в АД. Да ещё 20% актов теряла либо почта, либо бухгалтерия клиента.
Спас только переход на электронный документооборот (мы используем «Диадок»). Теперь электронный акт у нас бесплатный, а бумажный — только курьером за отдельные деньги. Это прям хорошо помогло.
Да, и еще. Не позволяйте бухгалтеру рулить бизнесом.
Договор
Веселее счетов и актов может быть только ДОГОВОР! Каждый третий клиент хочет его заключить, обязательно на бумаге, с мокрой печатью и подписью директора собственной кровью.
- Как это у вас нет договора? Вы работаете по оферте? Хорошо, нам подходит. Распечатайте её, подпишите, поставьте печать и высылайте Почтой России.
- Как это оферта не требует согласования и подписания? Ну хорошо, можете не присылать бумагу, пришлите скан.
- У наших юристов нашлось 128 замечаний к вашей оферте. Можете оперативно внести исправления? Заранее спасибо.
- Ну хорошо, мы согласны работать по оферте. Давайте только сначала подпишем соглашение о работе по оферте.
- Нет, мы категорически не согласны работать по оферте, обязательно нужен договор. Сколько-сколько он стоит? Мы готовы работать по оферте.
И вот это всё продолжается в бесконечных вариациях. Доброжелательность и терпение — ваши друзья.
Тарифы и цены
Тарифные планы в B2B обычно сложные. У нас, например, есть подписка с лимитами по фичам и объёмам, и есть отдельная оплата за каждую запись, да ещё с несколькими слоями скидок. Всё это усложняет жизнь как клиентам, так и команде.
Часто B2B прячут цены. Хотя мы сделали всё прозрачно, и прекрасно зашло.
Ловушки
В B2B клиенты любят (1) требовать сроки по конкретным фичам и (2) просить индивидуальные доработки. Называть сроки — плохая идея. А индивидуальные доработки — ОЧЕНЬ плохая идея.