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

🎲 22 апреля - опять играем!

Мы подготовили для вас 3 новых кризиса для симуляции!

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

😱 Второй кризис также про наши реалии, но многостронний.
Заказчик привлек на проект 2х подрядчиков, разделил между ними контуры автоматизации и... что-то пошло не так уже на этапе фиксации процессов "tobe".
3 команды, 6 участников.

😱 И, наконец, первый "фантастический" (он же наш третий) кризис с неограниченное количеством участников и 4 командами.
Кодовое название "Синий апельсин": про попытку договориться представителей корпораций, нашедших уникальный фрукт.

Какие кризисы будем отыгрывать на ближайшей игре 22 апреля - решать участникам 🫵

Ссылка для записи:
https://uc1.1c.ru/course/biznes-igra-krizis

#Обучение_РП

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

Мы не только учим, мы и сами учимся ☺️☺️☺️

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

Осталось всего 2 принципа ☺️

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

⚠️ Принцип №5 "Оплата и ввод в эксплуатацию"

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

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


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

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

Коллеги, добрый день.
Хочу поделиться новостью.

На прошлой неделе мы завершили обучение первого потока курса «1С:Аналитик. Практикум».
Учились 6 недель. За это время сделали кейс – 5 домашних задания, объединенных в единый поток работ аналитика на проекте.

Обсудили и проработали вот такую цепочку.
1️⃣ Обследование предприятия. Формирование дерева бизнес-процессов
Разобрали некоторые важные теоретические темы общие и уже по конкретной задаче обследования:
• Жизненный цикл проекта
• Задачи аналитика в фазах проекта
• Декомпозиция бизнес-процессов
• Фиксация функциональных требований
А в рамках домашнего задания поработали над формированием навыков сбора и анализа исходной информации по бизнес-процессам, а также потренировались формировать дерево бизнес-процессов.

2️⃣ Далее перешли к моделированию бизнес-процессов
Обсудили общие принципы моделирования и основные виды нотаций моделирования
А в рамках ДЗ трудились над моделированием бизнес-процессов и выстраивали взаимосвязи со смежными процессами.

3️⃣ Поработали с конфигурацией в рамках работы с требованиями и фиксированием функциональных разрывов
Тут обсуждали такие вопросы как:
• Анализ полноты и качества требований
• Систематизация требований
• Выявление функциональных разрывов

4️⃣ Куда ж без документов))) Проектирование системы. Состав и структура проектной документации
Разобрали виды документов, относящихся к проектированию.
И потренировались составялть Проектное решение.

5️⃣ Реализация / разработка ИС, тестирование ИС
Тут проговорили виды тестирования.
А в рамках самостоятельной работы разработали Сценарий тестирования ИС.

6️⃣ И завершающее – подготовка к эксплуатации
Тут тем много, мы их просто обсудили:
• Цели и задачи подготовки ИС к эксплуатации
• Виды эксплуатации ИС и ключевые отличия
• Анонс работ по подготовке системы к эксплуатации: Подготовка системы, организация миграции НСИ и начальных данных, настройка интеграций, подготовка персонала, организация службы поддержки

Достаточно активная и сложная программа.
И слушатели разделились на 2 категории:
✍️ те, кто активно работал в ходе курса, «выросли», и уже на последних занятия это было видно
📖 некоторые же попросили перенести обучение в следующий поток, чтобы до начала «прокачки» практики позаниматься теоретическими темами. Молодцы! Выбрали правильный подход и активную позицию – организовали свое обучение лаконично.

Коллеги, присоединяйтесь к нам! Присоединяйте своих коллег – аналитиков)
Следующий поток обучения 11 июня 2026 года
Ссылка для записи

#Обучение_РП

27 апреля 😮
«У природы нет плохой погоды» (с)

Здравствуйте, коллеги.

Для вас уже не секрет, что мы постоянно проводим бизнес-игры.
Отличный формат обучения, выявления зон роста для каждого участника индивидуально.
Почему индивидуально? А потому, что в ходе игры, каждый участник «показывает» себя – ведь такой уж это формат ☺️ И это позволяет тренерам поработать хард и софт-скиллс с каждым участником индивидуально.

Но я-то участвую в играх, как наблюдатель. Стараюсь собирать и обобщать, систематизировать…
И хочу с вами поделиться некоторыми выводами относительно того, какие зоны являются самыми непроработанными. И, на самом деле, я сама удивляюсь этим выводам, так как кажется, что это основное!!!
1️⃣ Часто путаются в жизненном цикле проекта – какие этапы нужны в проекте, зачем они нужны, какие работы выполняются в рамках каждого этапа. Т.е. по сути, не могут проработать жизненный цикл проекта, предложить его заказчику и, самое главное, пояснить и обосновать его для заказчика.
2️⃣ Деталь. Планируют и презентуют заказчику работы по описанию процессов, а нотаций не знают. Не до деталей, нет, а иногда даже правильных названий нотаций.
3️⃣ Путаются в понятии «Функциональный разрыв». Кажется, таком популярном в настоящее время.
4️⃣ Управленцы часто не умеют делегировать. Пытаются закрыть все вопросы сами. А в результате – провал, т.к. не знают (см. выше) нотаций, планов работ и целей исполнения работ и т.д. Итог тут печальный – провал встречи.
5️⃣«Неумение ставить на паузу». Поясню, ситуация… Заказчик задает вопрос, но ответа сразу нет. Вместо того, чтобы сказать «Ваш вопрос крайне важен, но в настоящий момент ответить на него сложно, (например) т.к. у нас на встрече нет предметника в данной области. Мы вернемся в офис, обсудим и отправим вам ответ письмом». Ведущий встречи начинает что-то отвечать, плавать в вопросе и, в результате, демонстрирует некомпетентность. Итог тот же самый – провал встречи.

Просто поделилась…
Коллеги, надо учиться, всегда надо учиться – не останавливаться…
Даже когда кажется, что знаешь все и все умеешь – ведь всегда есть зоны улучшения…

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

#Обучение_РП

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

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

⚠️ Принцип №6 "Скорость выполнения операций и типовой функционал"

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

Для договора:
Подрядчик обязуется обеспечить, что совокупные трудозатраты пользователей на выполнение операций в разрабатываемой системе (как типовых, так и доработанных) не превышают трудозатрат на выполнение аналогичных операций в исторической системе.
При этом Стороны исходят из того, что типовой (неизменённый) функционал платформы 1С:ЕРП по умолчанию соответствует данному требованию, если Заказчиком не доказано иное.
Если Подрядчик предлагает реализацию функции нетиповым способом (путём доработки), он обязан при согласовании перечня работ (Принцип №5) письменно подтвердить, что такая реализация не приведёт к превышению указанного порога трудозатрат. В случае последующего выявления превышения по вине нетиповой реализации Подрядчик устраняет его за свой счёт, а также компенсирует Заказчику расходы на проведение замеров.
Если в ходе эксплуатации Заказчик направит мотивированный запрос о превышении указанного порога, Стороны в рабочем порядке проводят совместное мероприятие (замеры, анализ, экспертную оценку) для проверки обоснованности обращения. Формат, сроки и методика проведения мероприятия определяются Сторонами по взаимной договорённости при получении запроса.
В случае подтверждения факта устойчивого (не разового) превышения трудозатрат пользователя, Подрядчика за свой счёт выполняет работы по оптимизации системы. Если превышение вызвано изменением исходных требований, аппаратного обеспечения или иными обстоятельствами, независящими от Подрядчика, Стороны обсуждают возможность доработок на условиях дополнительного соглашения.


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

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