Коллеги, добрый день.

Ранее в канале вы спрашивали про

«Обновление ГОСТ Р 7.0.97-2025»

Тема важная и мы постарались для Вас подготовить краткую и емкую информацию ⬇️

‼️ Самое важное. На этот вопрос можно посмотреть с 2 сторон:
🫲 Применение, точнее соблюдение ГОСТ в проектах внедрения системы Документооборота
🫱 Применение ГОСТ для оформления именно проектной документации в рамках проектов внедрения различных систем. Т.е. как мы должны оформлять протоколы, Уставы, предметные документы и т.д., чтобы соответствовать ГОСТ

"Применение, точнее соблюдение ГОСТ в проектах внедрения системы Документооборота".

1️⃣ Согласитесь, что в рамках проектной деятельности мы сталкиваемся с различными нормативными документами и ГОСТами, и знать все документы практически невозможно.

На примере проекта по внедрению систем электронного документооборота, по состоянию на август 2025 года выявили порядка 190 нормативно-правовых документов и стандартов, в той или иной степени влияющих на процессы документооборота и внедрения информационной системы документооборота (СЭД). Конечно, не все нормативные документы используются в рамках одного проекта одновременно.
Поэтому важно разобраться: какие из них влияют на проект, а какие нет.

Об этом мы рассказывали на Дне документооборота 2025.
На сайте фирмы 1С можно ознакомиться с презентацией доклада «Основные нормативные документы по управлению документами и архивному делу».

2️⃣ Как показывает практика, среди многообразия нормативных документов можно выделить один ГОСТ, который точно всегда нужно учитывать в проектах по внедрению СЭД, а именно ГОСТ Р 7.0.97-2025 «Система стандартов по информации, библиотечному и издательскому делу. Организационно-распорядительная документация. Требования к оформлению документов».

В 2025 году были внесены изменения в этот ГОСТ, издана новая редакция.

Если вы хотите узнать об этих изменениях, но не тратить при этом свое время на сравнение старой и новой версии, вам будет полезно ознакомиться со статьей о ключевых изменениях «Новый ГОСТ Р 7.0.97-2025: изменения в оформлении документов».

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

"Применение ГОСТ для оформления именно проектной документации в рамках проектов внедрения различных систем".

Важно понимать, что ГОСТы носят рекомендательный характер, и заказчик проекта, может настаивать применять шаблоны документов, разработанных по требованиям заказчика.
Это частое требование крупных корпораций: свой проектный офис, брендбук корпоративный, который распространяется не только на документы, но и на цвета, используемые в интерфейсах информационных систем.
И если в вашем случае, заказчик выставляет требование работать по своим шаблонам документов - работаем по правилам заказчика.

Долматова Елена
Фирма "1С"

#Предметные_вопросы

Как используют ТКВ?

Добрый день.
Этакий провокационный пост. Провокационный не для вас, скорее для меня 😮😌

Опять про технологии внедрения. Про 1С:ТКВ. Такую большую, сложную, непонятную 🤕

Говорят, что 1С:ТКВ не применима… 😮😮😮

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

В последнее время сталкиваюсь в 3 видами реакции на 1С:ТКВ. И звучат они примерно так:
1️⃣ 1С:ТКВ не применима в проектах, зачастую даже в корпоративных (причины называются разные и это тоже очень важно, можно отдельно обговорить этот вопрос)
2️⃣ 1С:ТКВ применима с адаптациями. То есть компании берут 1С:ТКВ читают ее, изучают, анализируют. И, или дополняют свою уже состоявшуюся технологию, или путем упрощения создают технологию по которой будут работать в компании. На мой взгляд, самый оптимальный вариант применения такого большого свода знаний, как ТКВ.
3️⃣ 1С:ТКВ иногда является даже базой для новых идей и инструментов. Об этом и на партнерском бывает говорят🙂

А вот вы знакомы с ТКВ?
Анализировали ли ее? ведь познакомиться мало, надо понять и прикинуть на себя.
Применяете в том или ином виде?

✏️ Поделитесь, пожалуйста, вашим мнением.

#Технологии_1С

Коллеги, здравствуйте.

Хочу поделиться с вами интересным документом, который попал ко мне в работу. Это проект "Принципов внедрения 1С", сформулированных командой заказчика. Это не техническое задание и не смета, а именно попытка сформировать "правила игры".

Предлагаю устроить открытый и, главное, честный разбор. ⚖️
Давайте попробуем абстрагироваться от привычной роли "исполнителя, который хочет минимизировать риски", и посмотрим на текст через призму здравого смысла и баланса интересов.

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

Я буду выкладывать принципы постепенно, чтобы каждый можно было обсудить отдельно.

✅ Сегодня начнем с Преамбулы и Принципа №1 "Применение стандартов".

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

Поехали! ⬇️

P.S. Если вы догадываетесь, кто автор — оставим догадки при себе. Важен именно документ и его суть

#Рассуждения_о_проектах

Итак...

Преамбула и Принцип №1 "Применение стандартов".

Без преукрас и первичных корректировок... Вот как есть...

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

⚠️ Принцип №1 "Применение стандартов"
Кратко:
Если есть конфликт интересов, и договор не дает ответ по ситуации, тогда Стороны обращаются к выбранному стандарту внедрения. Стандарт выбирается Сторонами совместно.

Для договора:
Вопросы, связанные с созданием, документированием, испытаниями и приемкой автоматизированной системы, не урегулированные действующими Договорами и иными согласованными Сторонами документами, разрешаются Сторонами с применением национальных стандартов Российской Федерации комплекса «Информационная технология. Комплекс стандартов на автоматизированные системы» (ГОСТ Р 59792-2021, ГОСТ Р 59793-2021, ГОСТ Р 59795-2021, ГОСТ 34.201-2020, ГОСТ 34.602-2020 и иные взаимосвязанные стандарты). При этом Стороны сохраняют право в рабочем порядке определять конкретные параметры и этапы реализации проекта, не противоречащие существу обязательств по Договору. В случае противоречий между условиями Договора и положениями указанных стандартов приоритет имеют условия Договора и согласованные Исходные требования.

💬 Давайте обсуждать

#Рассуждения_о_проектах

Здравствуйте.

☝️ Ранее мы затронули тему «Говорят, что 1С:ТКВ не применима… 😮😮😮»

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

〰️ Вспоминаю себя в начале карьерного пути.
На первом месте работы, слава Богу, была очень продвинутая компания в части управления проектами и там было все – и корп хранилища для проектов, и корп шаблоны и типовые формы документов и многое другое.
Потом была компания, где все только выстраивалось. Но зато там у меня уже была база, на которой можно «ехать». Взяла ее и стала применять ее в реалиях другой компании. Конечно, пришлось много переделывать и самое главное создавать с нуля! И вот тогда я думала «Ну где же взять хоть какие базовые шаблоны документов, хоть какое-то описание хода проекта?».

Знаете, наверно именно поэтому я сейчас и занимаюсь той работой, которой занимаюсь…

Так вот, искала документы, собирала проектные артефакты у команд, анализировала, делала шаблоны для компании.

И вот сейчас, когда подготовлены своды знаний, в которых много что есть, сталкиваюсь с тем, что:

1️⃣ Люди не хотят изучать. Мне кажется, это тот самый эффект, когда мозг сопротивляется обучению, как только может 🤯 Нормальное объяснимое состояние. Я его тоже часто переживаю 🥵

2️⃣ Еще люди, говорят, что слишком много написано ✏️✏️ ✏️✏️✏️. Ведь это надо прочитать 📕, над этим надо подумать 🥶, и надо взять в конкретный проект то, что нужно именно для него, проекта. И тут же, как будто прикрываются отрицанием «Мы не делаем так сложно, дайте краткий подходящий ‼️ВНИМАНИЕ‼️ на все случаи жизни подход».

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

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

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

3️⃣ Еще одно отрицание, которое я слышу «Давайте сделаем уникальные индивидуальные технологии для отрасли или для объема клиента». Но тут возникают все те же вопросы, что я описала выше. Ведь в рамках отрасли или в рамках ниши, в которой находится наш клиент, существуют абсолютно разные компании – по культуре, по стилю, по потребностям – и в результате по проекту. И как же сделать «типовой» жизненный цикл проекта тогда?

❓ Коллеги, может я привыкла работать по-старинке, индивидуально подходить к клиенту, думать о нем❓ И поэтому не вижу вариантов «упрощения» технологий. А иду через анализ ситуации и подбор подхода к конкретным условиям.

Подскажите, поделитесь вашими мнениями ✏️
Я-то описала свое видение, свой подход, свою идею работы с технологиями.

P.S. У Фирмы «1С» есть разные технологии.
Их разница концептуально заключается в 2 вещах:
✅ В подходе к проектированию системы – проектирование и описание всей системы или работа с функциональными разрывами
✅ В объеме «бюрократии» - протоколов, отчетов …

#Технологии_1С

И вот правда☺️☺️☺️ даже в этом посте слишком много написано🙂🙂🙂

Убить взглядом – убить словом…
Демотивировать одним предложением…
Этакий кейс, но психологический

Добрый день.
Поделюсь своим, даже не знаю, как сказать - шоком, открытием, … 😮🥶😭☹️😖 причем, спустя годы...

Встречалась со своим бывшем коллегой, моим бывшим подчиненным. Тем, с кем у меня прекрасные деловые и дружеские отношения по сей день и казалось безоблачная история отношений) 😘☺️

Говорили о мотивации, демотивации, о том, как руководитель должен относиться к подчиненному… В общем, вспоминали былое…

И тут я слышу...

Лен, а помнишь ситуацию…

Я пришел к тебе поговорить, потому что понял, что больше не могу делать проект, ну вот все …. не-мо-гу.
Пришел и говорю: «Лена, я больше не могу управлять этим проектом, сними с меня полномочия РП.»
А ты отвечаешь, и так просто отвечаешь, без эмоций: «И что? Получается я его должна делать?»

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

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

Ведь, правда, вроде ничего такого не сказала…

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

И тут такой провал для меня, хоть и из прошлой жизни… 😭😭😭

Добрый день.
Продолжаем ранее начатую тему ⬇️

Хочу поделиться с вами интересным документом, который попал ко мне в работу. Это проект "Принципов внедрения 1С", сформулированных командой заказчика. Это не техническое задание и не смета, а именно попытка сформировать "правила игры".

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

⚠️ Принцип №2 "Документирование"

Кратко:
Заказчик обязан предоставить необходимую информацию, а Подрядчик должен отразить её в документах. Если Заказчик предоставил информацию, но Подрядчик не отразил её в документах, то это ответственность Подрядчика.

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

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

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

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

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

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

💬 Коллеги, давайте обсуждать

#Рассуждения_о_проектах

Γειά σου, коллеги

Все не дает покоя мысль про технологи 🤕

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

А что такое вообще технология?
И, скажу честно, когда начинала писать ТКВ, я называла ее (ТКВ в смысле) методологией.

И мне подумалось, а может быть здесь кроется какая-то часть проблем. Ведь, как известно, «как корабль назовешь так он и поплывет».

Обратилась к все набирающему популярность ИИ 🤖

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

Далее проанализировала ваши ответы на мои вопросы о применении ТКВ. И ведь там были четкие ответы: в ТКВ нет инструментов, ТКВ не инструкция.

И смотрите, ведь все сходится.
Мое ощущение, восприятие, что ТКВ – это по сути методология. И ваши ожидания от набора состава ТКВ как технологии.

На самом деле получается, что ТКВ это скорее не технология, а методология – рекомендации как организовать проект, как делать проект, как контролировать ход проекта.

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

Вот это открытие! Точнее не открытие, а окончательное осмысление терминов, которые мы используем.

Как вы считаете, корректно ли я рассуждаю? ✍️

#Технологии_1С

Коллеги, добрый день, еще раз 🙂

Сегодня меня преследуют картинки-образы, то абсурдные, то живые нежные 🌸

Коллеги, весна 🌱☀️🌷🍀

Коллеги, добрый день.

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

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

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

И самый частый девиз при подготовке такого рода документов «Для всех и ни для кого» 😭😭😭

Посмотрите внимательно на саму дорожную карту ⬆️ Согласны?

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

А теперь давайте порассуждаем, как смотрят на такие документы заказчики:

〰️ Эта дорожная карта для меня? Так, а где «я»? Где мои «филиалы», тут вообще про это ничего нет. Ой, нет, написано – «представительства». Но у меня нет представительств… у меня филиалы…

✨ Говорят – будет пилот и тираж. Тааак, а кто будет пилотом, кто в тираже?

⚠️ Интересно… 2-3 представительства запущены. Так 2 или 3????

❓А у меня еще есть магазины. Где хоть слово про них…

📕 Мне нужно было автоматизировать 2 направления - оперативный учет и бухгалтерию. А вы запланировали эти 2 направления? - не вижу ничего про это в документе.

✅ ОЭ/ОПЭ. Простите, что это? Аааа, опытная и опытно промышленная. А почему через дробь? Так какая – опытная или опытно-промышленная?

И так далее…

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

А для этого важно:
1️⃣ Придерживаться терминологии заказчика
2️⃣ Не ограничиваться общими фразами, делать их более индивидуальными
3️⃣ Не забывать в документах отражать подходы и работы, которые призваны решить задачи заказчика, тем более, если заказчик их озвучил
4️⃣ Пусть лучше будет немного больше слов, но заказчик «узнает» себя в вашем предложении об организации проекта

#Рассуждения_о_проектах

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

И еще оговорка, в преддверии ваших комментариев, что предложенная карта не идеальна ☺️

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

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

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

И в ходе обсуждения этой темы от поступил запрос - "А как оценить эффективность работы Аналитика?"

Тема, на самом деле, весьма сложная.
Поэтому я прибегла к помощи коллеги - Шишкиной Ирины @shiiisha_i.
Интересного и яркого профессионала.

И она для нас подготовила свое мнение по данному вопросу. ⬇️

КАК ОЦЕНИТЬ ЭФФЕКТИВНОСТЬ БИЗНЕС-АНАЛИТИКА
Оценивать бизнес-аналитика сложно. Его работа — это качество требований, которые потом превращаются в продукт.
🦴🦴🦴🦴🦴
КТО ТАКОЙ БИЗНЕС-АНАЛИТИК?
Бизнес-аналитик — это переводчик между бизнесом и командой разработки.

Знает:
🕊️ Бизнес-процессы компании (как работает бизнес, какие боли, какие цели)
🕊️ Методологии анализа
🕊️ Инструменты визуализации
🕊️ Основы системного анализа
Умеет:
🕊️ Задавать правильные вопросы
🕊️ Структурировать хаос (собирать разрозненные хотелки в целостную картину)
🕊️ Документировать понятно (так, чтобы и бизнес понял, и разработчик не запутался)
🕊️ Управлять требованиями (приоритизировать, отслеживать изменения, фиксировать решения)
Делает фактически:
🕊️ Собирает требования от стейкхолдеров
🕊️ Анализирует и структурирует их
🕊️ Описывает в понятном для команды виде
🕊️ Согласовывает с бизнесом и командой
🕊️ Управляет изменениями требований в процессе разработки

⚠️ Чем он отличается от системного аналитика? С этим все просто - не путайте: бизнес-аналитик отвечает на вопрос «что делаем и зачем?», системный — «как это будет работать в системе?».
🪶🪶🪶
ЧТО ТАКОЕ ЭФФЕКТИВНЫЙ АНАЛИТИК?
Эффективный аналитик — это тот, кто за оптимальное количество ресурсов (люди, деньги, время) приносит максимально возможные результаты:
1️⃣ Оптимизация процесса (сделали быстрее, дешевле, качественнее)
2️⃣ Снижение потерь (убрали лишние согласования, ожидания, переделки)
3️⃣ Повышение эффективности процессов и отдельных процедур

Эффективность аналитика — это про влияние его действий и решений на бизнес-результат.

🪶🪶🪶
МЕТРИКИ ДЛЯ ОЦЕНКИ ЭФФЕКТИВНОСТИ АНАЛИТИКА
Выделяю три группы метрик для оценки: стратегические, тактические, функциональные.

1️⃣ГРУППА 1. СТРАТЕГИЧЕСКИЕ МЕТРИКИ (оцениваются спустя время)
Эти метрики показывают долгосрочный эффект работы аналитика. Их нельзя замерить в моменте — нужно дождаться завершения проекта или даже первых месяцев эксплуатации.

1️⃣ Достижение бизнес-целей проекта
2️⃣ Снижение операционных затрат
3️⃣ ROI проекта

2️⃣ГРУППА 2. ТАКТИЧЕСКИЕ МЕТРИКИ (в рамках проекта)
Эти метрики можно оценивать в процессе работы над проектом.

1️⃣ Количество итераций согласования требований
2️⃣ Доля изменений требований после начала разработки
3️⃣ Соответствие сроков аналитической фазы

3️⃣ГРУППА 3. ФУНКЦИОНАЛЬНЫЕ МЕТРИКИ (оценка профессиональной деятельности)
Эти метрики показывают, насколько аналитик владеет инструментарием и насколько эффективно его применяет.

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

🪶🪶🪶
КАК ОЦЕНИВАТЬ?
Эффективность аналитика не оценивается прямым наблюдением. Только измерениями и вычислениями. Именно поэтому эта функция так сложна в оценке. Чтобы оценить эффективность аналитика, необходимо владеть полными данными о процессах компании. А это удаётся единицам.
1️⃣ Шаг 1. Собрать базу. Нужно зафиксировать «как было»:

🕊️ Текущие бизнес-процессы (схемы)
🕊️ Текущие показатели (время, стоимость, качество)
🕊️ Текущие проблемы и потери

2️⃣ Шаг 2. Зафиксировать плановые показатели
Что ожидаем - какие метрики должны измениться и на сколько?
3️⃣ Шаг 3. Измерять в процессе
По тактическим и функциональным метрикам.
4️⃣ Шаг 4. Измерить после
По стратегическим метрикам — через 3-6 месяцев после внедрения.
5️⃣ Шаг 5. Сравнить и сделать выводы
🦴🦴🦴🦴🦴
ЧТО ДЕЛАТЬ, ЕСЛИ МЕТРИК НЕТ?
Начните собирать их прямо сейчас 🫤

@shiiisha_i
@neprostoidea