1. Что из себя представляют данные. Их виды и вводная в теорию корпоративных данных
2. Введение в кейсы: инеграционный кейс, кейс НСИ холдинга,  кейс сферы FCMG по мастер-данным и НСИ  и формирование команд 
3. Решение кейсов, где составим основные артефакты по данным в первом приближении и проведем сверку с теорией
4. Разбор ошибок и консультационная часть

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

• Дирекция 1С, как ключевой Центр компетенции 1С компании «Газпром нефть»

• Построение экосистемы 1С

• Технологии и механизмы разработки

• Планы развития

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

Как определить MVP продукта?
Как не тупить и быстро начать разработку?
Формирование пользовательской истории продукта. Формирование подзадач и задач для реализации. Релизы продукта.
Потренируемся на «Котиках» в командах. Теория и Практика вместе с Вами. Мастер-класс займет 1,5 часа. 4-5 команд по 5-6 человек (максимум 30 человек).

1. Методы сбора требований.
2. Как классифицировать требования.
3. Особенности сбора требований для продуктов 1С.
4. Появление новых требований (на сдаче работ заказчику)
5. Реестр требований.
6. Границы проекта и требования.

Наиболее частый вопрос, который задают Заказчики перед началом любого проекта по автоматизации: "А когда оно окупится и сколько денег принесёт?"
Вопрос сложный и не всегда напрямую связанный с автоматизацией.

Есть два экономических эффекта от автоматизации - прямой и косвенный. 
 
Прямой эффект может быть достигнут только если у нас в результате автоматизации увеличивается производительность труда. Например, до внедрения системы тратили на операцию 15 минут, после внедрения стали тратить 2 минуты.
Экономический эффект считается легко классическими инструментами инвестиционного анализа. 
 
Зачастую, если мы пытаемся оценить прямой эффект от внедрения систем 1С, он отрицательный. Почему? Очень просто - на внедрение и поддержку ИС надо тратить деньги (часто - очень большие), а даёт она на выходе только информацию. 
Однако, есть и косвенный эффект, который может быть значительно более существенным для бизнеса.
Сама по себе информация о том, что происходит в компании, ничего не экономит. Экономия достигается за счёт управленческих решений и инструментов управления, которые строятся на получаемом поле данных. 
Я хочу показать на двух практических примерах, какими именно могут быть принимаемые решения, как оценить возможный и достигнутый эффект, и как правильно преподнести это понимание Заказчику.

 В рамках интерактива:
- Поучаствуете в командной работе;
- Получите навык получения требований;
- Лучше поймете требования бизнеса и откуда они берутся;
- Сможете показать свои способности к анализу. 

Кейсы в интерактиве из реальных проектов!

Благодаря труду IT-специалистов, многие вещи сейчас можно сделать буквально нажатием одной кнопки: отправить деньги, заказать еду, купить одежду или записаться к врачу. Но сама деятельность айтишников довольно часто все еще требует применения длительного ручного труда. Мы решили внести свой вклад в устранение этого досадного недоразумения. Еще немного, и основу ITSM для вашей компании можно будет буквально за несколько минут накликать мышкой на сайте и скачать из интернета. Как? Расскажем на нашем докладе.
Приходите, будет интересно!

Формат: разбор реальной рабочей ситуации;
Дано: проектная команда внедрения, 18 сотрудников (РП, аналитики, программисты);
Проблема: есть сложности во внутренних коммуникациях и командном взаимодействии, случаются конфликты между ролями на проекте;
Задачи: повысить качество коммуникации сотрудников; сократить расходы, вызванные неэффективным взаимодействием в команде; сформировать общие правила взаимодействия между ролями на проекте; подготовить команду к предстоящим изменениям - введению новой системы мотивации и грейдирования;
Ожидаемый результат: повышение вовлеченности команды в принятие решений об изменениях; сформированные правила работы для команды; индивидуальные инструменты работы с командой для Руководителя;
Методы: групповая фасилитация; деловая игра с элементами проективных методик; анализ результативности команды (совместная работа HR и Руководителя направления);
Итоги работы: расскажем совместно с Руководителем направления в нашем выступлении :)

Про Scrum часто говорят: "Пока ты читаешь и смотришь материалы о том, как нужно внедрить его в команду, все кажется легко и просто. Но стоит взяться самому за дело, оказывается, что все вовсе не так".
И это действительно так. Есть много материалов, но все ли в них рассказано до конца или что-то упущено? Именно о том, что осталось за скобками, мы с вами и поговорим.
- А точно ли вам нужен Scrum?
- Соответствует ли ваша команда ценностям Scrum?
- Какие ошибки существуют при оценке в Story Points и как можно облегчить этот процесс?
- Как фасилитировать встречи команд и какие они, в принципе, бывают?
- Ретро как отдушина команды, но что может пойти не так?
- 100500 задач в backlog и "нам нужно срочно всё и сразу".
- "Добросим в запущенный спринт, ачетакова" - норма для вас, смерть для скрама.
- И самое главное - а все ли дойдут до конца?)

• Как мы разбивали 1С УТ на продукты и что из этого получилось
• Как я лидирую направление «Розница» • как запустили «почти что Scrum подход» и Kanban доски в Jira 
• Какими метриками пользуемся и как (SP, Lead Time, WIP) 
• Как коммитимся перед бизнесом за сроки и при чем тут перцинтиль

Этот доклад про подбор и развитие не только стажеров, но и любого разработчика. Я расскажу про свой опыт, попытаюсь развеять несколько мифов и покажу на примерах как выглядит стажерская программа в нашей компании:
- Зачем и кому нужны стажеры и джуны.
- Базовые принципы стажерской программы. Отбор и мотивация
- Личность наставника как эталон, и как не стать плохим примером
- Обучение через практику. Как ускорить обучение используя готовые кейсы
- Учебная программа как инструмент непрерывного развития. Как помочь опытному специалисту
- Навыки программирования это только часть навыков. Развиваем софт-скиллы и мышление

1. Краткое описание предприятия и объемов проектного управления (300 одновременных проектов ежегодно, около 2000 участников проектов)

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

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

- Понятие проектного решения – что это и зачем.

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

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

- Переход от визуализации к финальному варианту проектного решения.

- Демонстрация методики на конкретном практическом примере.

1. Предистория развития продукта 
2. Первые кейсы внедрения 
3. Разделение продуктовой разработки и направления внедрения 
4. Планы по развитию продукта и планы применения проектного управления во внедрении

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

1. SOA
Правила построения цифрового контура
Что такое сервис и почему в их определении сложности
Как сервисы должны взаимодействовать между собой
Организационный монолит.
Закон Мела Конви
7 признаков плохой архитектуры
3 признака хорошей архитектуры

Готовой методики описания и идеально подходящих продуктов не было.
Функциональный и организационный объем проекта.
Информационные кризисы и механизмы 1С:СППР 2 по их предотвращению. Применение основного функционала.
Особенности документации 1С:СППР 2.
Программное и аппаратное обеспечение среды 1С:СППР 2.
Действия команды проекта по устранению нестыковок и доработке продукта.
График работ в 1С:СППР 2 c привязкой к начальным этапам проекта.
Перспективные, как казалось, доработки продукта. А что на самом деле надо.

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

• Какие компетенции (знания, умения и качества) аналитика являются сейчас наиболее важными и при этом наиболее дефицитными? Каковы тенденции в требованиях к аналитикам

• Где брать или как нарабатывать эти компетенции?

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

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

Чтобы дискуссия была максимально полезной, мы заранее запустим сбор вопросов и пожеланий к обсуждению – следите за анонсами на канале конференции!

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

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

• Какие артефакты и бизнес-показатели ждать от исследований 
• Как ускорить процесс исследований 
• Чек-лист идеальной структуры исследователей 
• Кейсы настройки продуктово-исследовательских отделов

Дано:
- транснациональная корпорация - производитель продуктов питания;
- пилотный проект на две страны: Киргизия и Казахстан, с возможностью тиражирования не несколько других стран Центральной Азии;
- в каждой стране необходим регламентированный учёт на локальном плане счетов и учёт по стандартам GAAP;
- а бета-версия ERP World Edition выйдет только через год;)

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

1. Особенности проектов, где много разработки с "0"
2. Как снизить риски с минимальными затратами
3. Бизнес-моделирование и прототипирование
4. Инструменты бизнес-аналитика  

Цель доклада: Показать – в чем заключается ценность и значимость аналитиков в проектах автоматизации на базе 1С 

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

Я не согласна с таким подходом и на примере реального кейса хочу разобрать, почему именно АНАЛИТИК должен быть лидером проекта автоматизации
Обсудим, что аналитик – это не тот, кто сдал на спеца по складскому учету
Аналитик – это тот, кто разбирается во «внутрянке» происходящего на проекте.
Аналитик 1С – это тот, кто разбирается во внутреннем устройстве компании Заказчика, так же хорошо, как и в предлагаемой для автоматизации конфигурации.

Будем менять парадигму.

На мастер-классе сравним эффективность разных подходов к проектам автоматизации на базе 1С на примере реального кейса:
1 подход - традиционный – когда решения принимают РП и Разработчики, а аналитики выполняют роль консультантов
2 подход - нетрадиционный - когда лидером проекта выступает Аналитик, а РП и Разработчики выполняют свои функции в рамках решений аналитика

У вас есть идея, гипотеза, понимание, как мы можем работать лучше, идеи трансформации или просто предложение для команды. Вы предлагаете это команде и уверены, что им это ну если не сразу понравится, то точно хотя бы заинтересует. Но часто прямо сразу идет отторжение, нежелание пробовать новое. Это плохо? Нет, это нормально, это сработала часть мозга, которая вырабатывает удовольствие от привычного и стабильного.
Но как же их убедить? Можно, конечно, обвинить в закостенелости и призвать выйти из зоны комфорта, но, увы, это только усилит активность в тех частях мозга, которые не хотят изменения.
Мы попробуем другим способом, мы рассмотрим изменение с точки зрения баланса удовольствия в настоящем и будущем. Оно есть и там и там. Его надо перебалансировать. Для этого мы рассмотрим 5-компонентную структуру, которая поможет сформулировать вашу идею и предложение так, чтобы мозг активировал систему удовольствия от будущего и сам захотел меняться и пробовать новое.

При подготовке отчета по фактическому бюджету доходов и расходов появляется конфликт между правилами ведения бухгалтерского учета и необходимой оперативностью получения данных. И решение подобных проблем не обязательно должно лежать в области методологии учета.
В моем докладе мы рассмотрим:
- дилемму правил и гибкости при подготовке управленческой отчетности;
- что такое метод условных начислений;
- как он помогает сократить время подготовки БДР;
- как реализовать аккруалы в типовых конфигурациях 1С;
- основы ведения параллельного управленческого учета;
- реальные кейсы нашей компании.

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

1.Не слишком ли много нотаций? Какую и как выбрать?

2.С чего начать? Как обойтись 3-мя геометрическими фигурами? Правда ли «все гениальное просто»?

3.Примеры простых, удачных и не очень блок-схем. А чем они отличаются от удачных?

4.Где взять удачные примеры?

5.Какой инструментарий и в каких случаях использовать? 

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

План тренинга:
1. Немного теории про:

1.1. Предпосылки проекта (проблемы и тренды, которые привели к созданию проекта)
1.2. Цели, использование фильтров целей (SMART, PURE, CLEAR)
1.3. В каких проектных документах эти данные отражаем (паспорт и устав) и зачем они нужны.

2.1. Разделиться на команды не более 6 человек, не более 5 команд.
2.2. Придумать название команды и проект, над которым команда будет работать.
2.3. Для проекта сформулировать предпосылки и цели с учетом фильтров целей.
2.4. Каждая команда презентует свои результаты. Совместно с другими участниками вместе рефлексируем 
2.5. Общая рефлексия по тренингу (что не у всех получилось с первого раза, почему).

Что ждет бизнес от ИТ? Взгляд со стороны бизнеса

• Должен ли ИТ думать о бизнес-целях или это задача менеджера?

• ИТ-Стратегия - декларация или часть бизнеса?

• Неочевидные участники процесса автоматизации.

• Алгоритм проверки требования на бизнес-ценность.

• Кто может и должен инициировать и обосновать ценность требования?

• “Куда копать”, чтобы приносить большую пользу для бизнеса?

Тезисы:
1. Постановка задачи - от бухгалтерии к отделу поддержки
2. Постановка задачи - от отдела поддержки до подрядчика
3. Итерации - их проверка, контроль и правка.
4. Сдача работ бухгалтерии - оформление справки и технической документации для службы.
5. Опыт, сроки, результаты.

• Планируем свой продукт 
• Отвечаем на важные вопросы 
• Челлендж от организаторов

"У нас было два сотрудника техподдержки, семьдесят три клиента, пять коробочных решений, пара релизов в месяц, целое море вопросов в чате, литр рома и восемь часов свободного времени. Не то, чтобы это было критично для бизнеса, но когда у тебя телефонофобия, то к делу надо подходить серьезно".
В любое время одними из важнейших задач руководителя компании являются оптимизация расходов и ускорение процессов, даже если ты разработчик ПО. С увеличением количества действующих абонентских договоров, в нашем небольшом коллективе, на 100% состоящем из кодеров-интровертов, очень много времени стало отнимать общение с клиентами: консультации по типовым вопросам, уведомление о новых релизах и отправка их подписчикам, отслеживание завершения срока подписки и т.д. Заниматься этим неинтересно, особенно если ты разработчик ПО. Явно назрела необходимость автоматизации рутинных процессов, причем времени на создание личного кабинета было немного - один рабочий день. В докладе расскажем, с помощью каких инструментов и приемов мы это сделали, а на мастер-классе продемонстрируем ключевые моменты создания и запуска личного кабинета клиента.
"Можно повернуться спиной к человеку, но никогда нельзя поворачиваться спиной к клиенту. Особенно, когда договор подписан."

1. Исследования кадрового потенциала. Кадровый голод 2020-2025 годов, дефицит кандидатов на рынке: причины, последствия, решения.
2. Чем оценить и измерить потенциал сотрудников? Какой бывает потенциал, и что нужно исследовать именно вам?

1. Краткое описание "учебной ситуации": проблемы бизнеса, цель бизнеса, описание текущей ситуации. Даю начальную BPMN схему + бизнес-правила.
2. Работаем в группах. Пробуем бизнес-правила для "учебной ситуации" вместе рисовать в BPMN или описать это в другом формате. Например, классический формат функциональных требований
3. Теория по Таблицам принятия решений: что это, как их строят, примеры
4. Работаем в группах. Пробуем для "учебной ситуации" вместе составить таблицу принятия решений на основании бизнес-правил. Таблиц будет несколько, и они будут связаны между собой. Будем составлять поэтапно: сперва одна таблица, потом декомпозируем ее на части или... наоборот.
5. Пробуем визуализировать на схеме связи между таблицами принятия решений.
6. Подводим итоги: показываю требования BPMN + Таблицы + схемы связей таблиц.

Будет продемонстрирован процесс запуска веб-интерфейса для конфигурации 1C, настройка доступных клиенту услуг, учет обращений клиента. 

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

В фокусе внимания нашего совещания:
•  Энергия совещания: что ее убивает, что умножает.
•  Почему Папу Римского выбирают сутки, а stand-up meeting 15 минут.
•  Роли на совещании.
•  Кто или что ЦАРИТ у вас на совещаниях? Какие потребности реализуются сейчас, и как их возглавить.
•  Как перестать быть жертвой совещания.

1. Ключевые факторы, на которые стоит обращать внимание обеим сторонам на этапе предпродажи. 
2. Полнота и качество постановки задачи, описание и видение ожидаемого результата, выделяемые ресурсы на проект, управленческий ресурс – влияние на стоимость проекта, вероятность успешного старта проекта. 
3. Как разные подходы к оценке проектов влияют на предлагаемую Исполнителем стоимость проекта. Из чего складывается оценка Исполнителя. 
4.  Варианты изменения стоимости проекта со стороны Заказчика при сохранении неизменных функциональных рамок. 
5. Влияние не функциональных требований проекта на изменение стоимости проекта после его старта.

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

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

• ИТ-специалистов, 
• Бывших бухгалтеров 
• Начинающих специалистов 
• Как обучать аналитиков работе со справочниками и документами. 
• Универсальный отчет как инструмент аналитика.

• Почему backlog это совсем не начало работы команды.
• Как структурировать работу до бэклога. 
• Какие этапы важно не забыть (PBR, AC, DOR, Scoring, WSJF).
• 3H Таблица как инструмент быстрого принятия решений, что делать с новыми идеями.

Тезисы:
- Решение бизнес-задач по организации эффективной одновременной проектной и процессной деятельности, повышении объемов и рентабельности, увеличении денежного потока на базе «1С:УНФ+PM Управление проектной фирмой»;
- Интеграция «1С:PM Управление проектами» с Битрикс24;
- Создание импортонезависимого стэка управления проектной организацией при помощи «1С:PM Управление проектами»;
- Новая функциональность в 5 редакции «1С:PM Управление проектами»: работа с большими графиками проектов, план-факт-прогноз по ресурсам и бюджетам проектов и пр.

- Почему вывод РП без адаптации приводит к дополнительным рискам и факапам на проектах?
- Как "научить ученого" - сделать так чтобы опытный РП принял технологию компании и начал ее исполнять.
- Перевод технологии управления проектами и принятых в компании практик в рабочие (читабельные) материалы
- Трек как последовательность теоретических и практических задач
- Роль куратора в треке распаковки
- "Зачетка" руководителя проектов, как ее собрать
- Когда РП можно "выпускать в поля"?

Разберем все этапы адаптации РП-шников из нашего опыта: что получилось хорошо, а что пришлось переделать. В формате практикума попробуем составить ваш "трек РП" в первом, черновом варианте. Будет полезно руководителям проектных организаций, ИТ-руководителям, которым предстоит нанимать и выводить РП, конечно, самим РП, чтобы составить для себя план развития. А так же HR, перед которыми стоит задача адаптации новых РП-шников в коллективе.

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

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

• Проведут обследование процесса
• Определят потребность процесса в автоматизации
• Смоделируют логику работы ПО
• Определят состав объектов, необходимых для реализации этой логики

Разработка собственного модуля аренды в Спортмастере.
Ошибки в управлении проектом и как мы их решали. Модуль разрабатывался в конфигурации 1С:ERP, внедрение происходило в несколько этапов.
Первый этап включал в себя разработку основного функционала и запуск пилотных договоров в течение четырех месяцев.
Второй этап – разработка функционала и массовый перевод договоров аренды.
Третий этап- разработка функционала для специфических условий расчетов с контрагентами.

Будет интересно руководителям проектов, менеджерам проектов, аналитикам.

• Как быстро обучить пользователей «с нуля» и не сойти с ума. 
• Адаптация новых аналитиков. Научились делать это эффективно в сжатые сроки. 
• Как своевременно выявлять ошибки в новом функционале. Поделюсь инструментами

Вопросы:
Ошибки тайм-менеджмента
Цели и планирование
Мотивация при достижении целей

- Чем корп. проекты отличаются от "обычных"?
- На что влияет масштаб проекта и портрет его заказчика?
- Как осметчивать корп. проекты в условиях неопределенности требований и при этом фиксированного бюджета?
- На что влияет устойчивая проектная команда и выравнивание ресурсов в корп. проектах?
- Можно ли совмещать принципы agile с жесткими фиксированными договорами подряда на корп. проекты?
- Стоит ли управлять рисками корп. проектов и как это делать правильно?
- Как управлять бюджетами корп. проектов, чтобы не допускать убытки (перерасход ресурсов)?
- Насколько важно уложиться в сроки корп. проекта, или важнее сделать хорошо?
- Где брать корп. проекты на рынке
- Где они водятся и как их получить? И стоит ли ими заниматься в целом?

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

Цели  мастер-класса:
- знакомство участников с современными методами и инструментами бизнес-ТРИЗ.
- активизация инновационного потенциала участников.
- наглядно показать как применять на практике методы и инструменты ТРИЗ для решения бизнес-проблем.
- решение бизнес-проблем участников.

Инструменты:
-  Обзор парадигмы, ключевых концепций и целей современной технологии системных инноваций на основе ТРИЗ.
-  Идеальность – ключевая концепция ТРИЗ.
-  Конфликты и противоречия как основной барьер к решению бизнес проблем.
-  Приемы ТРИЗ для устранения конфликтов: поиск инновационных решений.
-  Практика с формулированием проблем и поиском инновационных решений с приемами ТРИЗ.
-  Дискуссии, вопросы и ответы.

При внедрении 1С ЕРП и обследовании предприятия, на какие аспекты необходимо обратить внимание, чтобы решить, где лучше автоматизировать бухгалтерский учет - в  1С:ERP или в 1С:Бухгалтерия. Или может клиенту нужен 1С:Управление холдингом?
Демонстрация на практических примерах.

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

• Как избежать внедрения сложных продуктов и подсистем, вроде BI, MDM, CRM, Бюджетирования и т.д., если вам оттуда нужна пара объектов.
• Как делать дешёвые интеграции и не заморачиваться с поиском специалистов по Конвертации данных.
• Как не попасть в УХу, если директор хочет красивые отчёты.

• Что такое CustDev и как его можно использовать в проектах 1С -
• Тестирование гипотез: как, зачем, по какой технологии  
• Валидация идей продукта: может ли идей быть больше чем одна?
•  Создание MVP и проверка его на пользователях 

Все, кто хоть раз занимался автоматизацией планирования, сталкивался с этими вопросами:

• Что должно входить в контур планирования (производства, закупок, продаж, финансов), если заказчик автоматизирует только одну область (например, производство) 
• Как собрать и гармонизировать встречные требования разных заинтересованных сторон 
• Где заканчивается зона ответственности ИТ-аналитика, как выявить риски смежных работ и что с этим делать 

• Мы рассмотрим применение CJM подхода, двухуровневого анализа бизнес-процессов и других методик для работы со сквозными требованиями. 
• Я покажу практические инструменты, которые использую для формализации требований: реестры процессов, карты НСИ и отчетности, матрицу интеграции. 
• Расскажу о технологии проведения встречных интервью и кросс-функциональных группах 
• Поговорим о том, кто такой Функциональный архитектор, его роль в проектах и требования к квалификации 

Как известно, рекомендуемый состав Agile-команды - не более 10 человек. А что делать, если для разработки продукта нужно больше, или гораздо больше? Scaled Agile Framework (SAFe) помогает в этом случае выстроить взаимодействие между командами. И PI-планирование (от слов Program Increment, а вовсе не Pi - пирог) - это ядро SAFe, когда за короткое время командам нужно состыковать между собой запросы менеджмента, свои возможности, риски и зависимости от других команд.
На деловой игре мы попробуем провести сокращенное pi-планирование по вымышленному продукту и познакомимся с форматом мероприятия.

Продолжительность: 2 часа

Всем участникам проектов внедрения знакомы пять главных «НЕ» :

1. НЕправильно просчитанный бюджет 
2. НЕзаинтересованность руководства 
3. НЕпрочное целеполагание 
4. НЕреализованные ожидания заказчика 
5. НЕжелание пользователей сотрудничать 

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

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

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

• Ломаем мозг заказчика. 1С "под капотом" — не равно "олд скул". 
• Отдельный интерфейс. Когда нужен, а когда нет. 
• Какие преимущества даёт нам движок v8. 
• Как правильно позиционировать преимущества.

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

На вопрос HR «Кем вы себя видите через 3… 5 лет?» - аналитики и руководители проектов 1С все чаще отвечают, что хотят стать руководителями подразделений или даже компаний. Рост в сторону ТОП-менеджмента – большая амбициозная цель для специалистов, чьей работой является автоматизация бизнеса. И, действительно, в процессе внедрения бизнес-приложений 1С в разных компаниях мы получаем большой пласт практических знаний о бизнес-процессах, о конъюнктуре отраслей. За продолжительное время проектов успеваем проникнуться реальной атмосферой управления бизнесами и их подразделениями. 
Целью своего выступления ставлю:
1.  Рассказать об обеих сторонах медали под названием «ТОП-менеджер», помочь аудитории под разными углами посмотреть на эту профессию.
2.  Провести интерактивное тестирование аудитории на предмет склонностей и базовых предпосылок перехода в роль ТОП-менеджера.
3.  Обработать результаты тестирования. Предоставить общую статистику по аудитории, а в течение недели с момента завершения Конференции – предоставить индивидуальные рекомендации слушателям по развитию тех или иных навыков (и конкретным способам), которые присущи руководителю, по сути – сформировать индивидуальные планы развития для всех заинтересованных.

Прошли очередные 3 месяца проекта, завершился один из его этапов. 

Ретроспектива одним днём - методика, которая позволяет команде в сжатые сроки в спокойном режиме проанализировать накопленный опыт и внести коррективы в проект:

• взглянуть на то как оно было на самом деле; 

• определить, что сработало, а что нет;

• понять что нужно изменить.

Поделимся методикой и инструментами проведения однодневной ретроспективы.

Вместе с вами разберем на примере эту методику.

Ценность такой ретроспективы:

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

• поможет минимизировать риски проекта;

• даст информацию для внесения корректив в технологию внедрения для “потомков” и последующих проектов.

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

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

За два часа вы проработаете кейсы с применением Business objective model, презентуете свое решение и ознакомитесь с тем, как проработали кейс другие. В заключение обменяемся мнениями и обсудим результаты. С собой унесете ценный опыт применения Business objective model и обратную связь от меня и коллег.

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

При выборе архитектуры информационных систем необходимо учитывать:

• Стратегию развития ИТ и компании на несколько лет вперед (ценрализация/ децентрализация, стэк технологий);

• Целевая бизнес-архитектура (бизнес-процессы, поставляемая ценность, информационные потоки);

• Нефункциональные требования;

• Количество и объем обрабатываемой информации с учетом ежегодного прироста;

• Ограничения и допущения со стороны технологического слоя архитектуры (оборудование, системное ПО, каналы связи, информационная безопасность);

• Смежные информационные системы, с которыми планируется взаимодействие, а также их планы по развитию;

• Возможность вендорской поддержки компонентов информационной системы.

Учет перечисленных факторов необходим для:

• функционирования информационной системы продолжительное время;

•  возможность развития информационной системы с минимальными затратами.

В рамках доклада расскажу:

• Как мы пришли к необходимости развития и формализации процесса управления архитектуры

• Какие функции выполняет архитектор информационных систем

• Какие методологии используем

• Какие программные инструментальные средства используем в условиях текущей макроэкономической обстановки

• Каким образом выстроено взаимодействие подразделений в части управления архитектурой

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

•    Описание структуры обмена (Дизайн интеграции)
•    Для чего используем xsd-схемы
•    Архитектура взаимодействия 1С с RabbitMQ
•    Настройка обмена в системе 1С

• Scrum не панацея, а узкоспециализированная практика.
• Релизы - разбор болей и решений.
• Планирование фич в разрезе направлений. 
• Организация эффективного взаимодействия.

Нефункциональные требования часто вызывают трудности у аналитика при работе с ними, а еще больше проблем они могут вызвать в случае их некачественной проработки.
В докладе систематизирую базовые знания о НФТ. Поговорим про то, как организовать процесс проработки НФТ, с кем нужно наладить коммуникацию и какими принципами лучше руководствоваться. Разберем несколько примеров где грамотная работа с НФТ принесла несомненную пользу, а плохая работа с НФТ привела к проблемам. А также приведу чек-лист для аналитика как не упустить НФТ при проработке требований.
План доклада:
1. Что такое НФТ?
2. Требования к видам обеспечения, переходные требования, ограничения и их отличия от НФТ
3. Почему НФТ это важно? Пара примеров из жизни, когда упущенные НФТ привели к серьезным последствиям
4. Классификация НФТ (SQuaRE, FURPS, BABOK и т.д.), примеры по типам
5. НФТ и атрибуты качества (SQuaRE, SPICE, Tick-IT)
6. Как выстроить процесс работы с НФТ:
- Новая функциольность / доработка
- Проактивная и реактивная работа с НФТ
- Коммуникационная модель и зоны ответственности при работе с НФТ
- С чего начать выстраивание процессов работы с НФТ в компании?
7. Примеры нестандартных решений, принятых после хорошей проработки НФТ
8. Чек-лист аналитика при работе с НФТ (триггеры наличия, приоритеты по типам, вопросы для выявления, как проверить НФТ на корректность, оправданность)

• матрица "голова-5-я точка". Почему нет правильных решений и откуда вообще такие идеи в нашей голове?
• кто такой руководитель, тушащий пожары, и руководитель от сердца? А что если перед решением не надо думать головой? Да не, бред.
• 4 ведущие стратегии лидера в проектной команде. Индивидуальная работа: оценка своих сотрудников по матрице, выявление лидера.
• работа в команде: составление портрета лидера с помощью карточек.

• проблемы с самоопределением лидера
• проблемы делегирования
• проблемы неэффективных решений
• проблемы авторитетности (низкой)

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

1.Зачем в нашем проекте нужна ER-диаграмма? Можно ли было обойтись без нее? 

2.Проектирование, документирование, сервис. Нормализация БД и ER. 

3.Какие инструменты использовать для ER-диаграммы? И для какой цели?

4.Как снизить трудозатраты при ее создании и актуализации? 

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

Мы с вами: разберем роль Agile Product Owner и её основные обязанности.
Поговорим про: карту коммуникаций жизненный цикл создания продукта, а также составим перечень необходимых hard & soft skills сформулируем топ основных качеств.

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

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

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

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

Продолжительность: 3 часа

1. Стоит ли компаниям с ЕРП, УХ, КА, выделять ЗУП в отдельный контур или удобство ведения учета в единой базе неоспоримо?
2. Кажется, что может быть сложного во внедрении зарплаты? Всё уже давно выяснили и определились, но есть нюансы
3. Порассуждаем о том, как может выглядеть инфраструктура информационных систем в крупных и средних компаниях, а также о том, где во всем этом место для ЗУП
 

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

•    5 минут теории про производственное планирование: как должно быть и как ситуация обстоит на большинстве российских заводов.
•    APS – автоматизация планирования.
•    Как составить ИТ ландшафт предприятия заказчика, чтобы в части планирования производства принести максимальную ценность Заказчику.
•    «Сложить, нельзя заменить»: ERP и APS в производственном планировании играют важные самостоятельные роли. Разберём, какие, и почему одно другое заменить не может.
•    Работа с данными: какие справочники в ERP системе важны, чтобы приступить к следующему шагу внедрение APS системы после ERP.
•    Разбор кейса интеграции системы 1C:ERP и Adeptik APS. Пользователь работает только в интерфейсах 1С ERP, а за Adeptik APS остаются сложные многокритериальные расчёты, результат которых возвращается в 1С ERP. Внедрение на заводе производства углеграфитовой продукции, проект реализуется в партнёрстве с ООО "Вайзэдвайс".

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

• Lean Canvas - краткий шаблон "правильных вопросов" 
• Ключевые вопросы о продукте на которые нужно ответить 
• Ключевые вопросы о рынке 
• Инструментарий 
• Что дальше? Финансовый план, бизнес план... 
•  Поиск инвестора, тестирование гипотез

За время мастер класса проанализируем приближенную к реальности бизнес-задачу и разложим ее на:
- Use case Diagram
- Class Diagram
- Statechart Diagram
- Activity Diagram
- Sequence Diagram

Познакомимся с основными видами диаграмм UML и разберемся с PlantUML

Участвуя в мастер-классе, Вы сможете посмотреть на свою проблему/ситуацию/вопрос с точки зрения технологии Социократия 3.0, вы найдете универсальный набор проверенных временем понятий, принципов и практик для повышения эффективности, уровня вовлеченности в организации.
Навык, который отработаете на мастер-классе, поможет Вам успешно справляться со сложной и непредсказуемой средой. Сама методология Социократия 3.0 (S3) предлагает Вам лишь набор паттернов (инструментов), которые можно применять шаг за шагом — нет никакой необходимости внезапно и радикально что-то менять или составлять долгосрочный план изменений:
— Просто начните с выявления насущных потребностей и выберите одну-две практики или принципа, которые могут помочь.
— После, двигайтесь в своем ритме и по мере движения совершенствуйте навыки и вырабатывайте гибкое, социократическое мировоззрение.
Мастер-класс часть No1:
Что будет: Знакомство с паттернами методологии Социократия 3.0 (S3). Рассмотрение ценности паттерна «Навигация через напряжение», и отработка навыка замечать напряжение. Драйвер - как инструмент.
Мастер-класс часть No2:
Что будет: Разбор и отработка эффективных методов взаимодействия с применением паттернов Социократии 3.0 (S3).

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

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

В данном докладе мы поговорим о простом, но очень изящном решении этой проблемы: создание структурированной системы на базе конфигурации 1С: Управление задачами с использованием JIRA и Confluence.

Коротко о том, какие вопросы мы рассмотрим:
- управление задачами и документацией различного уровня в одной программе;
- удобство ведения задач;
- ведение документации в разрезе объектов метаданных;
- использование JIRA/Confluence REST API;
- и другое.

• Рассказывем что такое сторителлинг, базовые принципы.
• Показываем примеры сторителлинга 
• С участниками выбираем их продукты и/или продукты 1С, участники рассказывают историю про них.

1.Опыт переходов с исторических систем на 1С:ERP
         a.Переключение существующих интеграций VS Разработка новых
2.Подходы к интеграции НСИ 
         a.Централизованный VS Гибридный
         b.Архитектурные принципы и частые ошибки
3.Аналитики, Разработчики и Архитекторы на интеграциях
         a.Кто что делает и за что отвечает 
4.Инструменты аналитика 
         a.Исследование базы, трассировка, мэппинг и др.
         b.Моделирование БП и переносы между базами
5.Опыт использования сервисной шины интеграции ESB

Успех проекта внедрения информационной системы во многом определяется эффективностью коммуникаций: внутри проектной команды, с руководством и с ключевыми специалистами Заказчика.
И не всегда взаимодействие происходит в дружеской и конструктивной обстановке. Для многих ИТ-экспертов взаимодействие в режиме конфликта – является большой проблемой, отнимающей массу энергии.
Решением проблемы является классификация людей, с которыми происходит взаимодействие на несколько типов и понимание как общаться и выстраивать взаимопонимание с каждым типом.
Типологий личности много, преимущества типологии DISC, во-первых, в ее простоте, а во-вторых, в легкости применения. Почти всегда ведущий тип считывается при первом же разговоре, по одежде, аксессуарам и т.д. И дальше нужно только выбрать корректный способ взаимодействия.
От типа личности зависит многое, мы будем рассматривать их с точки зрения работы в проекте: сильные и слабые стороны типов, способы передачи информации и т.д.
Уделим внимание особенностям взаимодействия с клиентами в зависимости от их типов. Рассмотрим примеры.
Рассмотрим применение DISC в команде: какие типы для каких видов работ хороши, а где их можно усилить. Рассмотрим примеры.
Применим типологию к себе: какие сильные и слабые стороны есть у вас, и как с ними работать.
Типология личности DISC стала корпоративным стандартом во многих технологических компаниях. В частности, в ВЦ «Раздолье» ( razdolie.ru ).
Планируем провести доклад с краткой информацией о способах применения типологии и мастер-класс с практикой.

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

• Что такое «дизайн-мышление»: этапы процесса, примеры использования, преимущества и недостатки 
•  Практическая часть: 

1. Выбор объекта исследования (например, ресторан в Прибалтийской, где все пообедали – в этом случае желательно проводить воркшоп во второй половине дня); 
2. Этап «Эмпатия»: провести интервью, составить карту эмпатии 
3. Этап «Фокусировка»: составить карту путешествия пользователя (CJM); 
4. Этап «Генерация идей»: провести мозговой штурм; 
5. Этап «Выбор идей»: выбрать топ 1 идею голосованием; 
6. Этап «Прототипирование»: разработать прототип решения; 
7. Этап «Тестирование»: протестировать и презентовать разработанный прототип 

• Зачем нужно учитывать legacy-системы?  

• "Подводные камни" в оценке сроков реализации проекта в экосистеме. 

• Сравнение плановых и фактических затрат и сроков на проектах внедрения ЭДО: 
• а) для складских форм М-8 и М-15 в МТС
• б) для региональных биллингов 
• Продукт в интеграционном проекте: карта рисков.

1.  Рассмотрим фундаментальные основы анализа на примере разбора общих принципов работы, которыми следует руководствоваться аналитику данных.
2.  Глоссарий, вокабуляр. Разберём почему важен понятий аппарат, как с ним работать и как приводить его к единому знаменателю.
3.  «Analyze it!». Глубина анализа и последствия погружения в недра данных.
4.  Критическое мышление. Технология развития такого мышления.
5.  От теории к практике. Как это работает: сквозной пример работы аналитика со сложным заказчиком на основании применения вышеперечисленных в докладе пунктов.
6.  Что делать, если … ? Горячая подборка проблемных ситуаций работы аналитика.

• Кто такой Аналитик и какова его роль на проекте- Отсутствие готовности к совместной работе: разработчик работать в команде с аналитиком и аналитик погружаться в техническую сторону реализации задачи
• Как организовать совместную работу
• Реальный кейс как включение Аналитика на проект позволило нам вывести систему из кризиса и закрыть технический долг

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

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

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

• Эволюция целеполагания: MBO/KPI, S.M.A.R.T., OKR; 
• OKR и KPI: отличия, область применения и взаимосвязь между инструментами;
• Организационные уровни и ритмы постановки OKR.

ПП «1С:ERP» имеет сложную внутреннюю структуру, и при этом очень слабую «защиту от дурака». Пользователи легко могут совершать ошибки, которые приводят к «расползанию» регистров и проводок.
Пока мы, внедренцы, ведем проект, то следим за этим сами. А потом мы уходим, оставляя программу на местную ИТ-службу. Но, к сожалению, не всегда в ИТ-службе работают достаточно компетентные сотрудники. Тогда и начинаются проблемы. В организации появляются новые пользователи, которые не внимательно читают инструкции, появляются новые операции, да и сама программа меняется от версии к версии. В итоге начинают появляться ошибки и расхождения в данных, которые сразу не заметны. А спустя несколько месяцев их количество возрастает до уровня «ваша программа вообще не работает».
Вариант – предложить инструмент для регулярного контроля корректности данных в информационной базе. Фактически – это набор отчетов, за каждым из которых должен быть закреплен ответственный сотрудник. Даже если сам он не сумеет решить проблему, то хотя бы сможет ее вовремя заметить и сигнализировать тому, кто сопровождает систему.

• Принцип Винни Пуха ”Входим и выходим” - что такое сонастройка и зачем она нужна
• Как мы все НЕ умеем задавать уточняющие вопросы
• Зачем мне ваша реакция
• Логика быстрых умных организаций - консент. Good enough for now, safe enough to try (Достаточно хорошо на сейчас, достаточно безопасно, чтобы попробовать)
• 1+1 = оооочень много. Что такое интеграция

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

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

Рассмотрим работу аналитика через призму Lean
- 8 видов потерь согласно Lean-методологии
- причины и проявления в работе аналитика
- способы предотвращения и устранения

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

1. Почему заваливаются проекты
Свой кейс: Более детально разбираем каждый проект и выявляем ключевые причины успеха и неуспеха проекта. В кейсе подробно разберем, что пошло не так и, как правильно нужно было вести «утонувший» проект.
Интерактив с залом: Собираем примеры неудачных проектов, провалившихся по причине неправильно сформированных ожиданий. Вместе вырабатываем правильные алгоритмы взаимодействия с клиентом
2. Определение ключевых целей проекта
Свой кейс: На примере кейса разбираем вопрос: на каких этапах нужно начитать работать с ожиданиями заказчика, и в какой момент формируются цели проекта.
Интерактив с залом: Разбираем примеры неправильно сформированных ожиданий и целей на разных этапах проекта и вместе вырабатываем правила взаимодействия с клиентом.
3. Управление ожиданиями со стороны Заказчика
Свой кейс: На примере проектов определяем, а чьими ожиданиями нужно управлять. Обсудим зачем использовать Устав проекта, и для чего нужны протоколы встреч. Обсудим ключевые пункты устава: сроки, стоимость, задачи проекта, риски, ресурсы и т.д.
Интерактив с залом: Обсудим вопрос, а помогают ли вам протоколы встреч и устав при ведении проекта.
4. Управления ожиданиями команды со стороны Исполнителя
Свой кейс: На примере проектов определяем, чьими ожиданиями нужно управлять со стороны Исполнителя.
Интерактив с залом: Разбираем примеры: что бывает, если не работать с ожиданиями Исполнителя, и вырабатываем правила работы в команде
5. Открытость в проекте
Свой кейс: На примере своих проектов разбираем, какое ПО использовали для взаимодействия с заказчиком, обсудим основные плюсы и минусы.
Интерактив с залом: Обсуждаем, какое ПО наиболее подходит для совместного взаимодействия с заказчиком на проекте.
6. Как корректно завершить проект

Свой кейс: На примере своих проектов разберу, как перевести проект из стадии «Проект» в стадию «Сервис».  

Интерактив с залом: Обсудим со слушателями ключевой вопрос: как вывести команду проекта и передать сопровождение на сервис. Совместно выработаем правила передачи клиента на сервис.

Бизнес-игра на тему внедрения единого информационного ландшафта в среднем и крупном бизнесе за счёт единства данных.
На игре мы смоделируем «близко к реальности» процесс интеграции и внедрения системы управления мастер данными MDM систему в связку УС(ERP/УТ)-MDM-WMS-DWH.
Участники активности:
•  Узнают, чем отличаются MD от НСИ
•  На практике научатся даже на первый взгляд понимать состав данных для интеграций
•  На практике научатся разделять критически важные данные и второстепенные
•  Методом пересечений массивов научатся находить «ключи интеграции»
•  Поймут, что самое главное – большой сводный документ с «дизайном интеграции»
На примере сделанной интеграции 1С-ERP->MDM->WMS axelot X5->DWH в ГК «Айсберри» разберём основные ошибки которые совершаются на уровне от аналитика до архитектора.

1. Знакомьтесь! Тот самый документ "Производство без заказа" 
2. Формирование кейсов:

 a. Кейс 1. Во всем важен баланс. Особенно, если учет ведется на поточном производстве, а баланс - материальный
 b. Кейс 2. Смешанное ведение учета производства. Разделяем датчики и контроль материального баланса, а потом властвуем
 c. Кейс 3. Зачем в книжном учете производства строить учет материалов по влаге

3. Пришли. Настроили. Управляем производством без формирования этапов и заказов
4. Что еще важно знать? Простои, выработка по рабочим центрам, фиксация контролируемых параметров производства.

Возможно ли проекты автоматизации выполнять вовремя, качественно и за обозначенный бюджет или это утопия? Это общее мероприятие для бизнес-заказчиков, пользователей, аналитиков, разработчиков и руководителей проектов. Участники будут разбиты на команды, в рамках которой будут рассматривать кейсы и принимать решения, как остаться в рамках обозначенного бюджета, сроков и заявленного качества проекта.
Желающие предложить свои кейсы для разбора могут заранее записаться и подготовить необходимые вводные для работы.
Продолжительность 1,5-2 часа

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

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

О Soft skills говорят ото всюду, но не всегда есть ответы на следующие вопросы:
- скиллов много, а какие из них нужны в IT?
- все скиллы хороши, но как же их накачать?
- а как заставить хотеть качать скиллы, да хотя бы аналитиков 1С, не говоря о разработчиках?

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

План:
1. Предыстория – как мы пришли к тому что Soft skills сейчас нужны для работы.
2. Составляем список Soft skills для аналитиков. Совместная работа в группах.
3. Капелька опыта – матрица скиллов, получившаяся в нашей компании
4. Мозгоштурм, как сделать так, чтобы сотрудники начали тренировки.
5. Как мы совсем недавно отправились в это увлекательное путешествие и что из этого вышло (Опыт моей компании от разработки до прокачки)

После года интенсивной работы в управленческой базе 1С накапливается большое количество информации. Алчные до анализа аналитики загружают разработчиков 1С  большим объемом работ по созданию разных отчетов из базы данных. Это нужно, чтобы получить крупицы «золотой» информации, необходимой для принятия правильного управленческого решения.
Как результат, загружены разработчики, нагружено железо, перегружены регистры, чешут голову администраторы по железу..... бюджет поддержки такой системы летит к небесам...

 Что можно сделать в данной ситуации? Создать микросервис с внешней БД, и выгрузить туда всю информацию необходимую для анализа. Это позволит освободить немного базу 1С, снизить нагрузку, освободить разработчика 1С, а полученную БД отдать под самую простую BI  систему (Yandex datalens) в руки аналитиков и юниор разработчиков, чтобы они сами могли вывести отчеты и взаимосвязи.
В рамках мастер-класса рассмотрим 2 варианта организации подобного микросервиса: на VDS и на YandexCloud с помощью современного и быстрого языка Golang. Попробуем выгрузить из 1С,принять данные, положить их в БД, а затем анализировать БД с помощью datalens.
Голосуй, если тебе интересен этот мастер-класс.

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

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

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

Вы сможете сделать короткую презентацию своей идеи или готового программного продукта и получить обратную связь от коллег. Для этого заранее пришлите заявку с коротким описанием идеи или продукта на почту event@infostart.ru

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

В этот раз полем битвы будет территория, больше привычная для аналитиков и консультантов: в режиме 1С:Предприятия участникам предстоит решить задачи по анализу и обработке данных. Будет не только весело, но и практически полезно! 

Что то пошло не так? Ошибки ищи тут:

1. Взаимоотношения сторон; 
2. Жизненный цикл проекта; 
3. Жизненный цикл продукта; 
4. Команда исполнителя. 

• превращаете мысли в описание; 
• описание в сервис; 
• сервис в пользу; 
• пользу в деньги. 

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

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

Принципы и алгоритмы конструктивного разговора.
Обычная жизнь человека в ИТ - это много-много общения. С заказчиками, коллегами, руководством своим и "из соседнего офиса". Очень часто бывает так, что происходят разговоры, после которых внутри вскипает океан эмоций. В самом широком диапазоне - от недоумения до гнева "Пошли революцию делать". Поддавшись на эмоции люди способны натворить много странных вещей, от которых не будет пользы ни самому "творцу", ни окружающим, ни делу, в котором работаем. Бывает, что Заказчик (да-да, с большой буквы, очень уважаемый) меняет требования, настаивает на бесплатной доработке... И отказать неловко, и делать не хочется. Или сотрудник раз за разом "косячит", не желая исправлять поведение.
На МК изучим принципы и алгоритм, используя которые можно разрешить подобные ситуации, сохранив отношения надолго. Всего 4 принципа и 1 несложный алгоритм + несколько неявных тонкостей.
Продолжительность: ориентировочно 2 часа

• Составляем доску Discovery (Miro);
• Наполняем его;
• Просчитываем WIP лимиты (min max);
• Расписываем каденции KANBAN.

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

• Виды методик управления рисками. 
• Тепловая карта - как основной инструмент формирования карты рисков. 
• Влияние рисков на бюджет проекта и договора. 
• Управление рисками при еженедельных совещаниях на проекте. 

Комплексное управление компанией - всегда сложная задача. Это вопрос, который касается всех: разработчиков продуктов, стартапов, системных интеграторов, и даже корпораций.
ТОП-менеджмент всегда хочет знать, реализованы ли стратегические цели. Но в чем роль аналитиков и как они взаимодействуют со стратегией?
Все ли действия руководителей проектов напрямую связаны со стратегическим уровнем?
Каждая ли метрика продукта влияет на верхнеуровневые цели?

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

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

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

Причина в том, что ни заказчик, ни менеджер, ни даже исполнитель - никогда не знает за сколько времени можно сделать ту или иную задачу с вероятностью хотя бы 80%. Каждый оперирует только своим опытом, и интуицией. И кажется, что нет никаких объективных данных, на которые можно было бы опираться при прогнозировании сроков задач. Но есть выход. Как правило, сейчас для учета задач используются различные программы таск-трекеры (JIRA, TFS, Trello и тд), в которых накоплено большое количество исторических данных по разным задачам. Обработав эти данные, можно на их основе спрогнозировать с 80-90% вероятностью срок исполнения задачи любого типа. Никакой магии. Немного математика и теории вероятностей. Приходите и узнаете, как это можно использовать.