Как мы оптимизировали процессы внедрения 1С: проектная методология КРОК

15.05.24

Бизнес-анализ - Внедрение изменений

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

Меня зовут Павел Власов. За моими плечами 20 лет проектного опыта автоматизации процессов на 1С: 9 лет работы в сети франчайзи 1С и 11 лет в КРОК на проектах внедрений 1С федерального масштаба в корпоративном сегменте. Сейчас руковожу группой консультантов по 1С и управляю производственными процессами масштабных проектов по внедрению 1С в роли старшего технического менеджера. 

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

 


 

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

2. Нечеткие зоны ответственности в команде: один человек – и консультант, и программист, и архитектор.

3. Один консультант работает сразу на 2-4 проектах.

4. Команда проекта часто меняется, на разных этапах разные люди.

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

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

7. «Проектное рабство» — нет четких границ в проекте, договора типовые, ТЗ размытое с неопределенными рамками и границами, а «клиент всегда прав».

8. Сроки не учитываются, главное – взять проект, «а там разберемся».

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

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

Кому и зачем нужны единые проектные подходы

У всех, кто работает на корпоративном рынке, есть своя методология внедрения в том или ином виде. У нас – тоже своя. Мы долго выстраивали процессы – КРОК работает с 1С уже более 13 лет. В основу нашего проектного подхода легла методология Oracle AIM. Когда-то консультанты КРОК получили опыт внедрения ERP-систем этого вендора. За 10 лет мы оптимизировали эту методологию под 1С, исключили лишние документы и адаптировали ее под ГОСТ 34-й серии. У нас много заказчиков, которым нужно, чтобы структура документов соответствовала этому стандарту.

 

Вот что помогает сделать проектное производство управляемым и эффективным:

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

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

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

 

От методологии и инструментов — к проектной культуре

 

 

Во главе всего — люди и их проектная культура. Фундаментом выступает используемая методология и технологии под которые заточены инструменты. Тогда проект любого масштаба  и производственные процессы в нем можно сделать управляемыми — настроенными с нуля в «чистом поле» без потери времени на подготовку и отладку производства.

 

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

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

 

Более подробно про это можно прочесть в нашей другой статье: «Управление требованиями и проектирование в СППР с использованием методологии AIM»‎. 

Мы составляем и записываем инструкции в видеоформате через Vanessa Automation, Yandex SpeechKit и 1Script. Благодаря этому мы получили возможность пересобирать их в автоматическом режиме и поддерживать в актуальном состоянии, даже если изменились элементы интерфейса.

Для управления задачами, декомпозиции, планирования, используем Project и Jira. Для нас Jira — это инструмент управления детальными задачами, трекер, для отслеживания статуса задач и фиксации трудозатрат. К Jira можно подключить и заказчика, и нашу команду. Она позволяет оперативно и прозрачно контролировать ход выполнения работ, выявляя отклонения на каждом этапе проекта.

 

Типичная задача в Jira

 

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

 

Структура проектной команды

 

 

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

Основное управление проектом осуществляют два менеджера — технический менеджер и менеджер проекта.

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

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

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

 

 

Технический архитектор 

Функциональный архитектор

Тимлид для группы

До 10 разработчиков

До 10 консультантов разных грейдов 

(от junior до senior)

Зона ответственности

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

- валидация функциональных разрывов на непротиворечивость и техническую реализуемость;

- помощь консультантам в выборе варианта реализации требований;

- согласование постановок задач разработчикам / функциональных дизайнов разработки (ФДР)

- оценка доработок;

- управление разработкой по спринтам, контроль сроков и трудозатрат по разработке;

- формирование регламента разработки и контроль его исполнения;

- контроль качества кода: code-review, анализ кода, автотесты;

- интеграционная архитектура;

- сайзинг и требования к железу; 

- нагрузочное тестирование;

- подготовка стенда разработки;

- подготовка обновлений и релизов.

- управление консультантами;

- функциональная архитектура;

- полнота каталога процессов, требований, форм, доработок

- выбор оптимального способа реализации требований / согласование функциональных дизайнов разработки (ФДР)

- функциональное проектирование;

- единообразие, унификация создаваемых решений на уровне подсистемы или всей системы;

- полнота, консистентность системы;

- архитектура взаимодействия со смежными системами;

- полнота тестирования.

Основной фокус

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

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

Цель

Система спроектирована и разработана в срок с требуемым качеством без превышения запланированных трудозатрат по разработке.

Заранее выявлены и устранены риски по производительности. 

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

Количество на проекте

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

В больших проектах бывает несколько функциональных архитекторов — на каждую подсистему свой. 


 

 

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

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

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

 

Процессный подход в нашей методологии

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

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

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

 

 

Подсистемы, блоки

ОТЗ: Функциональная архитектура

Бизнес-процессы

ОТЗ: Каталог БП

Требования
и функциональные разрывы

ЧТЗ: Модели БП, Альбом форм, Каталог требований

Доработки

ЧТЗ: Список доработок

Сценарии сквозного
кросс-функционального end-to-end тестирования

Программа и методика испытаний

Инструкции пользователей

Инструкция пользователя

 

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

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

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

В привязке к бизнес-процессам и/или шагам БП регистрируются требования:

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

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

Похожие требования на доработку мы объединяем в один предмет доработки (ФДР) / проектное решение. Это предмет доработки, имеющий самостоятельную ценность или функциональность. Его можно отдельно передать заказчику под протокол. Например, если заказчику требуются уведомления по электронной почте, все связанные с этим требования целесообразно объединить в один ФДР по доработке системы уведомлений. Такой подход позволяет структурировать доработки системы и облегчает передачу результатов работ заказчику.

 

Подход по этапам работ и отчетным документам

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

Здесь мы определяем функциональные границы проекта: декомпозируем систему на подсистемы, подсистему на блоки, блоки на бизнес-процессы. 

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

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

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

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

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

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

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

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

 

  1. Моделирование бизнес-процессов

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

  1. Проектирование и разработка 

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

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

  1. ПСИ

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

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

  1. Подготовка к опытно-промышленной эксплуатации

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

  1. Опытно-промышленная эксплуатация

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

 

Методология на примере

Рассмотрим, как все это работает на практике. Допустим, у нас проект с 9 подсистемами, 278 бизнес-процессами и множеством интеграций. Эта информация собрана на этапе предпроектного обследования.

 

 

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

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

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

 

 

У нас 9 подсистем, значит, нужно 9 отчетных документов. Их разработка и согласование превращается минимум в 18 задач.

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

Понятно, что вносить и администрировать все 2300 задач в Project — очень сложно. Поэтому в Project вносятся задачи по спринтам и подсистемам. В итоге в Project в данном примере получается около 600 задач, связанных с общим статусом работ, а детальные планы формируются либо в Jira, либо в Excel.

 

Заключение

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

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

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

методология управление командой управление проектами проектная культура

См. также

Анализ бизнес-процессов Внедрение изменений Бесплатно (free)

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

23.09.2024    274    0    Radio_Analyst    1    

3

Agile Внедрение изменений Бесплатно (free)

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

13.09.2024    2221    0    glebushka    3    

7

Инструменты управления проектом Внедрение изменений Бесплатно (free)

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

12.09.2024    299    0    ermakovalekseyv    0    

2

Внедрение изменений Бесплатно (free)

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

11.09.2024    566    0    cybrat    0    

2

Внедрение изменений Бесплатно (free)

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

21.08.2024    2436    52    Laya    3    

20

Внедрение изменений Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

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

19.08.2024    9394    0    vladshelshel    7    

4

Оптимизация бизнес-процессов Взгляд со стороны Заказчика Внедрение изменений Платформа 1С v8.3 Бесплатно (free)

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

13.08.2024    842    0    avermakov1986    5    

4

Внедрение изменений Бесплатно (free)

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

30.07.2024    885    0    MichaelMontrel    2    

6
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. muskul 15.05.24 10:07 Сейчас в теме
А у кого то есть методики как "перетащить" эдо и егаис в новую чистенькую БД?
3. DDA4746 16.05.24 08:47 Сейчас в теме
(1) Мой вам совет - запишитесь на консультацию (с)
:))
6. Дмитрий74Чел 238 16.05.24 14:33 Сейчас в теме
2. Birby 112 15.05.24 21:15 Сейчас в теме
Шикарный материал! Хочу у вас работать!)
7. Дмитрий74Чел 238 16.05.24 14:34 Сейчас в теме
4. titanium2008 46 16.05.24 09:02 Сейчас в теме
AIM оракла универсален, молодцы что применили его для 1с.
dimaster; +1 Ответить
5. cesar 62 16.05.24 14:05 Сейчас в теме
(2) Спасибо, мы всегда открыты к сотрудничеству
16. Ski4life 22.08.24 18:03 Сейчас в теме
(5) надоела кустарщина на проектах. разделяю ваш подход, где методика поддержана технологией ведения проектов, как к вам попасть? все HRы похоже в отпусках..
8. imm0rtal 15 18.05.24 06:59 Сейчас в теме
(2) не смешите мои тапки.
Спросите лучше автора, отчего в офисе КРОК так много горящих окон по вечерам.
13. cesar 62 23.05.24 11:11 Сейчас в теме
(8) Вообще по опыту в период запуска в ОПЭ часто приходится работать больше 8ч. Но в такие периоды чаще всего работа идет преимущественно на территории заказчика, а не в офисе КРОК. Есть и гибридный формат работы, удаленно/офис. Есть стажеры в комнате, которые работают в некоторые дни по вечерам, так как днем есть учеба. В офисе КРОК много кто работает, даже есть те, кто арендует у нас рабочие места. По горящему свету в окнах здания КРОК судить о средней загрузке команд на проектах 1С это все равно, что судить о происходящем в мире на основании того, что сказали по первому каналу.
У нас все люди взрослые и сами решают со скольки до скольки, а также откуда они сегодня работают, мы работаем на результат, а не на часы в офисе.
14. imm0rtal 15 23.05.24 12:22 Сейчас в теме
(13) ахах
это только джуниорам в уши лить.
9. ermilowww 18.05.24 23:38 Сейчас в теме
Отличная статья!
1. Подскажите, на этапе интервьюирования от пользователей Заказчика собираются всё таки требования к системе?
2. Процессный подход вы применятете на дальнейших этапах внедрения проекта и в какой то момент соединяете изначальные требования с автоматизируемыми процессами? Если, да то подскажите в какой момент соединяются требования с процессами
10. cesar 62 20.05.24 09:31 Сейчас в теме
(9)
1. а)Собираются бизнес требования к Системе (это используется в каталоге БП в описании БП) + б)цели/ожидания по каждой подсистеме от ключевых пользователей Заказчика (это отдельный раздел ОТЗ) + в)текущие проблемы автоматизации (это отдельный раздел ОТЗ). Эти верхнеуровневые бизнес-требования (а), которые позволяют сформировать каталог автоматизируемых бизнес-процессов до 4-го уровня (уровень операций) с описанием и дать точную оценку проекта в ОТЗ (ресурнсый план, дорожную карту). Данные требования записываются в описание процесса (раздел 4.2 ОТЗ по ГОСТу с функциональными требованиями представляется в виде каталога автоматизируемых БП по каждой подсистеме). Т.е. даже уже здесь по итогу интервью требования привязаны к процессам, не просто к Подсистеме или Системе в целом. И делается предварительная оценка степени их покрытия типовым функционалом. Но детальный список требований и окончательный реестр доработок рождается только после моделирования и демонстрации каждого процесса в Системе и фиксируются в ЧТЗ на каждую подсистему. Только там можно убедить заказчика использовать ту методику которая заложена в типовом решении или выявить наоборот новые детальные требования.
2. Изначальные требования по результатам моделирования так и остаются в каталоге бизнес-процессов в текстовом описании процесса, но уточняются формулировки и сам состав процессов (обычно что-то укрупняется что-то добавляется и каталог БП после моделирования может уточниться примерно на 10-15%). А детальные требования регистрируются поштучно и тоже привязываются к процессам и даже шагам процесса. Автоматически кодируются и далее классифицируются.
11. dock 44 22.05.24 00:20 Сейчас в теме
1. "Управление задачами: Project, Jira, Excel"
а) почему не 1С СППР? или другие решения на 1С (тоже хватает).
б) почему Jira? Есть уже очень много отечественных решений. В текущих реалиях Atlassian и Microsoft сами толкают нас на "импортозамещение"

2. "Библиотека, коммуникации: Jive, MS Teams, мессенджеры"
а что из этого относится к "библиотека" ?

3. Судя по содержанию статьи, документации "генерируется" очень много (ТЗ, ЧТЗ, общее ТЗ, Устав проекта и т.д.). Как "ведете" документацию? Т.е. "пишите" в Word/Excel и "храните" в обычной "сетевой шаре" или же используете специализированную систему? На мой взгляд очень важен вопрос методологии и инструментарий разработки и ведения именно документации.
12. cesar 62 23.05.24 10:32 Сейчас в теме
(11)
1а - СППР нужно дорабатывать под трекер задач и формирование уведомлений по жизненному циклу задач, интерфейсно и отображения дашбордов по статистике задач, а также для учета трудозатрат, пока используем Jira т.к. там все пока устраивает.
1б - есть Российская Eva - аналог Jira, Confluence. Возможно в будущем на нее будем переходить.2.
2 - проектная библиотека - Jive (для артефактов) + Teams (для коммуникации, некоторых рабочих файлов где одновременное параллельное редактирование)
3 - фиолетовым на рисунке в разделе "1. Моделирование бизнес-процессов" указаны артефакты по всем этапам проекта в формате Word, которые автоматически генерируется из доработанного 1С:СППР через бесшовную интеграции с 1С:ДО, либо Excel которые формируются на основе отчетов из СППР. Остальные на базе шаблонов и примеров в ручную (они не такие массовые от всего объема проектной документации).
15. dock 44 23.05.24 21:32 Сейчас в теме
(12) Благодарю за развернутый ответ!
В качестве системы учета задач (а заодно и wiki системы) порекомендую рассмотреть Devprom ALM (отечественная система управления жизненным циклом ПО).
По моему сугубо личному мнению, всё-таки нужно выбирать не "аналог Jira", а удобную систему под свои требования.
17. user2107161 27.09.24 11:43 Сейчас в теме
Этап Предпроектного обследования - я правильно понимаю, что он проводится до заключения договора (т.к. проекта еще нет). И все работы проводятся бесплатно?
Если так- есть ли какой то лимит по затратам на этот этап?
Как выцепляете ресурсы с активных проектов на реализации (требуются же самые квалифицированные ресурсы - чтобы их показать Заказчику + провести грамотно провести обследование и планирование) ?
Оставьте свое сообщение