10 тенденций аналитики данных от Gather

ПервоИсточник: Gartner Top 10 Data and Analytics Trends for 2021

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

• Ускорение изменений в обработке данных, в построении и использовании аналитики: использование инноваций в области искусственного интеллекта, улучшенные методы компоновки данных, гибкая и эффективная интеграция разнообразных источников данных.
• Операционализация стоимости бизнеса за счет более эффективных XOps: эффективные решения и аналитика как неотъемлемая часть бизнеса.
• Все - распределенное: гибкое соотношение данных и анализа данных для широкой аудитории, с широким охватом объектов.

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

Тренд №1: Smarter, more responsible, scalable AI. Более умный, надежный и масштабируемый ИИ.

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

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

Тренд No. 2: Composable data and analytics. Компонуемые данные и аналитика.

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

Тренд №3: Data fabric as the foundation. Фабрика данных как основа.

Архитектура фабрики данных позволяет поддерживать компонуемые данные и аналитику. Фабрика данных сокращает время на проектирование интеграции на 30%, развертывание - на 30%,  обслуживание - на 70%. Это связано с тем, что технология фабрики данных позволяет повторно использовать и комбинировать различных стили интеграции данных. Кроме того, фабрики данных могут использовать технологии хабов данных, озер данных и хранилищ данных, а также поддерживать новые подходы и инструменты.

Тренд № 4: From big to small and wide data. От больших данных к малым и широким по охвату данных.

Широкие по охвату данные обрабатываются методами «X-аналитики» и позволяют анализировать небольшие и разнообразные (широкие), неструктурированные и структурированные источников данных для повышения осведомленности о контексте принятия решения.

Тренд № 5: XOps

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

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

Тренд № 6: Engineered decision intelligence. Инженерный анализ решений.

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

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

Тренд 7. Data and analytics as a core business function. Данные и аналитика как основная бизнес-функция.

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

Тренд № 8: Graph relates everything. Графика связывает все.

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

Тренд № 9: The rise of the augmenter consumer. Рост числа потребителей с дополненным возможностями

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

Тренд № 10. Data and analytics at the edge. Периферийные данные и аналитика.

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

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

Ссылка:

https://www.gartner.com/smarterwithgartner/gartner-top-10-data-and-analytics-trends-for-2021/

Управление изменениями при внедрении ERP

Управление изменениями - это процесс подготовки сотрудников для успешной реализации изменений.

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

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

Общий же расклад в деле внедрения ERP примерно такой:

Управлять изменения необходимо:

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

Сравним управление изменениями и управление проектом. Всего можно выделить пять основных этапов управления проектом:

• инициирование,
• планирование,
• выполнение,
• мониторинг,
• закрытие.

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

Управление изменениями больше ориентировано на то, чтобы персонал был готов принять изменения, которые привносят проекты.

Вот несколько вопросов, которые стоят перед менеджером по изменениям:

• Как проект меняет бизнес-процессы?
• Будут ли изменения ролей?
• Как проект повлияет на организационные структуры?
• Как сотрудники относятся к изменениям?
• Как снизить сопротивление сотрудников?

Три этапа управления

1. Подготовка к переменам

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

2. Управление изменениями

На данном этапе основное внимание уделяется выполнению плана управления изменениями для подготовки персонала к новым технологиям и процессам.

Это должно включать:

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

3. Подкрепление и усиление перемен

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

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

На этапе подкрепления используются показатели оценки заинтересованности, формируемые по ходу процесса внедрения.

Общие вопросы, которые могут использоваться для оценки заинтересованности:

• Действительно ли сотрудники принимают новый путь или по-прежнему придерживаются старого?
• Где пробелы в знаниях сотрудников?
• Где пробелы в удобстве использования?
• Какие индивидуальне и командные успехи?

Пятиэтапная модель управления изменениями

АДКАР - это пятиэтапная модель управления изменениями. Буквы означают:

• A: (Awareness) Осознание необходимости перемен.
• D: (Desire) Желание поддержать изменение.
• K: (Knowledge) Знание - как изменяться.
• А: (Ability) Способность усваивать новые навыки и модели поведения.
• R: (Reinforcement) Подкрепление для сохранения изменений во времени.

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

Неэффективные "философии" управления изменениями

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

1. Отсутствие управления организационными изменениями. Многие организации вообще игнорируют управление изменениями.

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

3. «Они изменятся, потому что я так сказал». Это распространненая "философия" в кабинетах совета директоров и в кабинетах правления. Иногда трудно убедить руководителей в том, что этот подход не так прост, как кажется. Сотрудники могут открыто заявлять, что они готовы к изменениям, но в то же время, сотрудники "оснащены" тонкими и скрытыми формами сопротивления, разрушительными и незаметными большинству руководителей.

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

9 советов по управлению изменениями

1. Используйте систематический подход

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

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

• Оценка воздействия изменений.
• Оценка готовности бизнеса.
• Анализ заинтересованных сторон.

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

Фокус-группы полезны по нескольким причинам:

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

2. Соберите команду управления изменениями

В команду должны входить:

• Исполнительные и высшие руководители
• Руководители и руководители отделов
• Специалисты предметной области
• Специалисты по управлению изменениями.

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

3. Используйте энтузиастов перемен

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

4. Начните изменения сверху

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

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

Как получить поддержку со стороны руководства? Начните с вопросов:

• Как проект сократит расходы или какие выгоды принесет бизнесу?
• Как проект повлияет на отношение заинтересованных сторон?
• Как проект решит проблемы основных заинтересованных сторон?
• Как цели проекта соотносятся с бизнес-задачами?
• Сколько будет стоить проект?
• Какая ожидаемая рентабельность инвестиций?

Руководителям нравится конкретика, поэтому уделите внимание подробностям. 

• Какие конкретные бизнес-преимущества принесет  внедрение ERP? 
• Улучшит ли это взаимодействие и интеграцию между отделами? 
• Улучшит ли это способность компании обслуживать клиентов? 

Оцените преимущества ERP как можно точнее.

5. Адресуйте изменения всем уровням компании

Получив поддержку C-Suite, вы сможете вносить изменения на всех уровнях организации. Здесь вы можете использовать результаты оценки воздействия изменений.

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

 6. Сосредоточьтесь на культуре

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

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

7. Разработайте и следуйте коммуникационному плану

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

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

8. Организуйте обучение ERP

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

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

9. Продолжайте мероприятия адаптации пользователей и после запуска

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

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

Построение качественного обзора и преодоление нежелания проводить опросы

Первые шаги

• Устраните отрицательное слово "обзор", "опрос" из своего словаря  - вместо этого используйте - формирование «целевой обратной связи» с целью улучшения внедрения ERP.
• Позиционируйте опрос так, чтобы он исходил от высокопоставленных лидеров  - Воспользуйтесь возможностью передать влиятельные сообщения руководства.
• Разберитесь с историей обзоров и опросов организации  - как они использовались в прошлом и каково было их восприятие? Был ли опрос мучительно длинным и громоздким для заполнения? Были ли понятны результаты обзора или они кого-то поставили в тупик?

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

Советы обеспечения успеха

Определите вашу аудиторию и цели:

• Вы пытаетесь оценить удовлетворенность текущими или прошлыми проектами? 
• Вы пытаетесь определить группы сопротивления изменениям? 
• Вы пытаетесь степенрь понимания целей проекта и готовность к решению задач?

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

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

Чего следует избегать

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

Проекты не должны быть мрачными и ужасными

Четыре способа, которыми помогут сделать внедрение ERP менее мрачным.

1. Дайте хорошее и звучное имя проекту (брендирование проекта)

В начале внедрения ERP руководство и команда проекта должны спонсировать конкурс по названию проекта. Цель состоит в том, чтобы придумать такое название проекта, которое будет  отражать суть проекта и соответствовать корпоративной культуре.

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

2. Празднуйте маленькие победы

Учитывая, что внедрение большинства ERP занимает несколько лет, важно отмечать небольшие победы на протяжении всего процесса. Празднование можно проводить по мере достижения ключевых этапов проекта.

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

3. Признавайте индивидуальный вклад сотрудников

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

4. Проводите собрания

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

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

5 причин использовать управления изменениями сверху-вниз

1. Стандартизация и масштабируемость требуют проведения изменений сверху-вниз

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

Это ключевая причина, почему изменение и направление, установленное сверху, имеют решающее значение для успешного внедрения ERP.

2. Настройка - это симптом управления изменениями снизу-вверх

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

Верно и обратное: чем меньше вы настраиваете программное обеспечение ERP во время внедрения, тем больше потребуется управления изменениями. Это не обязательно плохо, поскольку настройка может быть дороже (особенно в долгосрочной перспективе), чем управление изменениями.

3. Принятие стратегических решений начинается сверху

Независимо от того, насколько талантливы, лояльны или готовы к изменениям ваши  сотрудники, неразумно ожидать, чтоони мастера стратегии.

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

4. Ограниченные ресурсы могут быть распределены только руководителями

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

5. Потеря общей картины хода при использовании подхода сниза-вверх

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

Почему перемены так сложны (согласно науке)

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

Вот что вам нужно знать о науке сопротивления изменениям:

1. Люди - рабы привычки

Исследователи определили, что люди чувствуют себя наиболее комфортно, когда они день за днем ​​заняты предсказуемой деятельностью в одном и том же контексте. Любое отклонение от этого распорядка может оказаться трудным. Это верно даже тогда, когда изменения могут быть полезными.

2. Изменения вызывают стресс и подавленность

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

3. Люди жаждут уверенности

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

4. Люди знают, что изменения могут привести к непредвиденным проблемам

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

.

Согласно заметке What is Change Management?

Зачем управлять изменениями

Изменения связаны не только с корпоративными проектами. На самом деле изменения постоянны, поэтому управление изменениями - постоянно.

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

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

Ниже распространенные причины использования методологии и инструментов управления изменениями.

1. Увеличение преимуществ и выгод

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

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

2. "Укоренение" будущих изменений

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

3. Согласование организационной практики и ценностей

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

4. Сохранение конкурентоспособности

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

5. Снижение сопротивления изменениям

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

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

6. Уточнение деталей проекта

Одна из причин неудач проектов - нечеткая и непоследовательная коммуникационная стратегия.

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

7. Повышение рентабельности инвестиций

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

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

Приоритет управления изменениями

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

По мотивам перевод статьи:
What are the Reasons for Change Management (Other Than an ERP Project)? by Panorama Consulting Group | Jan 11, 2021

Этика и искусственный интеллект

Что есть душа?

Есть ли это некоторый объект с соответствующией интенцией или это только интенция, которая присуща только мыслящему объекту.

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

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

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

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

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

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

Но это уж слишком абстрактная схема. А абстрактная схема - это идеальный объект. Не реальный. Путь к реальным объектам лежит через конкретизацию абстракции и таких конкретизации много.

Пример такой конкретизации может быть и таким.

Ниже "сэмпл" из книги "21 урок для XXI века". Юваль Ной Харари  

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

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

Разумеется, философские алгоритмы никогда не будут идеальными. Ошибки неизбежны, и они будут приводить к травмам, смертям и крайне запутанным судебным разбирательствам. (Впервые в истории у вас появится возможность подать в суд на философа за пагубные последствия его учения, потому что впервые в истории вы сможете доказать прямую причинно-следственную связь между философскими идеями и реальными событиями.) Однако для победы над водителями из плоти и крови алгоритмам вовсе не требуется совершенство. Достаточно просто быть лучше людей. Учитывая, что каждый год водители убивают на дорогах больше миллиона человек, это не такая уж трудная задача.

Разумеется, философы редко соглашаются друг с другом в том, какое поведение считать этичным, а какое нет. Лишь немногие решения «проблемы вагонетки» удовлетворили всех философов, а мнение таких сторонников консеквенциализма, как Джон Стюарт Милль (он оценивал поступки по их последствиям), прямо противоположно мнению сторонников деонтологии, к которым принадлежал Иммануил Кант (он оценивал поступки по отношению к абсолютным законам). Должна ли компания Tesla, чтобы продолжать выпускать автомобили, занять в этом запутанном вопросе определенную позицию?

Возможно, Tesla предоставит выбор рынку. Скажем, компания выпустит две модели беспилотного автомобиля: «Альтруист» и «Эгоист». В опасной ситуации «Альтруист» будет жертвовать владельцем ради общего блага, а «Эгоист» предпримет все возможное, чтобы спасти владельца, даже если для этого придется убить двоих детей. Потребители приобретут ту модель, которая больше соответствует их философским взглядам. Если большинство покупателей предпочтет модель «Эгоист», вины Tesla в этом не будет. В конце концов, клиент всегда прав.

Это не шутка. В исследовании, проведенном в 2015 году, испытуемым предлагали гипотетический сценарий, по которому беспилотный автомобиль вот-вот наедет на нескольких пешеходов. Большинство сказали, что в такой ситуации машина должна спасать пешеходов даже ценой жизни владельца. Но когда их спросили, купят ли они автомобиль, запрограммированный жертвовать владельцем ради общего блага, большинство опрошенных ответили отрицательно. Для себя они предпочли бы модель «Эгоист»[63].

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

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

Умные рабочие места

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

Ускорителем (акселератором) развития интеллектуальных рабочих пространств стал и COVID-19 Эпидемия заставляет перепроектировать физические пространства для обеспечения социального дистанцирования и рассматривать новые способы организации дистанционной работы.

Одним из элементов интеллектуальных рабочих пространств является концепт "рабочего стола как услуги". Рабочий стол как услуга (DaaS) предоставляет пользователю по его запросу виртуализированный рабочий стола, при этом не имеет значения точка, в которую доставляет эта услуга. Тем самым обеспечивает доступ пользователя к рабочему месту из удаленного расположения. Соответственно, такая услуга как удаленный рабочих стол должна быть спроектирована, подготовлена и развернута. В процессе же эксплуатации эта услуга должна поддерживать, включая исправление ошибок и предоставление необходимых ресурсов для размещения контента рабочего стола. Критичным для этой услуги является устойчивость и непрерываность предоставления услуги.

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

6 тенденций в цикле рекламы Gartner для цифровых рабочих мест, 2020 г.

Определите для себя

Определите для себя, что для вас значат эти слова

СМЫСЛ
СВОБОДА
ВЕРА
УМ, РАЦИОНАЛЬНОСТЬ, НАУКА
ДУША
ДУХ

СТРАТЕГИЯ
УПРАВЛЕНИЕ
МЕНЕДЖМЕНТ
МАРКЕТИНГ

ЧЕЛОВЕК
ЛИЧНОСТЬ
ЛИДЕР, ВОЖДЬ, НАЧАЛЬНИК, ПОДЧИНЕННЫЙ, РАБ

КОМАНДА, БАНДА
ГРУППА, КОЛЛЕКТИВ
ЭТНОС, НАРОД

ДОБРО, ЗЛО
ИСТИНА, ЛОЖЬ, ПРАВДА
КРАСОТА
ЛЮБОВЬ, ДРУЖБА, НЕНАВИСТЬ
ПРЕДАННОСТЬ, ПРЕДАТЕЛЬСТВО, ЛОЯЛЬНОСТЬ, ВЕРНОСТЬ

ЖИЗНЬ 

СМЕРТЬ

Технический долг как метафора программной инженерии

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

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

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

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

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

Общие причины технического долга:

• Давление бизнеса, когда бизнесу требуется выпустить ПО раньше, чем будут сделаны все необходимые изменения; это может вылиться в накопление технического долга.
• Отсутствие процессов или понимания проблемы накопления технического долга, особенно если бизнес не принимает решения без учёта последствий.
• Сильная связанность компонент, особенно в том случае, если декомпозиция системы выполнена неправильно или негибко.
• Отсутствие тестов — ускоренная разработка и применение быстрых рискованных исправлений («костылей») для исправления ошибок.
• Отсутствие документации. Работа, необходимая для создания вспомогательной документации, — это также долг, который должен быть оплачен.
• Отсутствие взаимодействия между командами, неэффективное управление знаниями в организации. Например, отсутствие наставничества в команде разработчиков.
• Отложенный рефакторинг — чем дольше задерживается рефакторинг, и чем больше написано кода, использующего текущее состояние проекта, тем больше накапливается технический долг, который нужно "оплатить" при следующем рефакторинге.
• Отсутствие опыта, когда разработчики просто не умеют проектировать программные системы или писать качественный код.

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

Накопление технического долга является основной причиной превышения сроков выполнения проектов. Трудно оценить, сколько именно работы необходимо выполнить для погашения долга. Неопределённое количество незавершённой работы добавляется в проект с каждым изменением. Сроки «горят», когда в проекте приходит понимание того, что есть ещё гораздо больше незавершённой работы (долга), чем времени для её завершения. Чтобы иметь предсказуемые графики выпуска, команда разработчиков должна ограничить количество выполняемой работы до такого, которое позволило бы минимизировать объёмы незавершённой ранее работы (долга).

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

При накоплении технического долга растет энтропия ПО, а рефакторинг может привести к сокращению энтропии ПО.

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

Мэнни Леман предложил несколько законов в части описания проблем создания ПО, из которых стоит упомянуть следующие два:

• Используемая компьютерная программа будет модифицирована;
• Когда компьютерная программа модифицируется, её сложность увеличивается, при условии что никто этому не препятствует.