Мы запустили рубрику “Вопрос дня” для того, чтобы немного показать вам внутреннюю кухню проекта. Как вы уже смогли заметить, обращения в службу поддержки бывают разными. Иногда слушатели просят тренера поделиться своим реальным личным практическим опытом и высказать экспертное мнение. Если сам тренер не против, то можно и поделиться, тем более, что есть чем :)
Вопрос
Ответ
Считаю, что у меня достаточно большая практика внедрения (20+ проектов) систем ERP на крупных предприятиях и холдингах (1000+ рабочих мест) и каждый раз внедрение сопровождалось значительными доработками прикладного решения. Я считаю, что это нормально и для себя объясняю следующим образом: если есть крупное предприятие/холдинг, которое долгое время ведет свою хозяйственную деятельность, значит, оно прибыльно или, как минимум, безубыточно. Значит, в процессе своей хозяйственной деятельности оно предлагает рынку и обществу в целом какие-то уникальные товары и услуги, которые те готовы оплачивать, и в структуре своей бизнес-модели имеет уникальные бизнес-процессы (технологические, организационные, финансовые и т.п.), которые не могут скопировать его конкуренты.
Когда мы приходим на такое предприятие с типовым программным продуктом, мы должны:
- На хорошем уровне знать бизнес-модель и процессы, заложенные в этот программный продукт (чтобы не изобретать велосипед там, где не нужно, и предлагать типовую функциональность)
- Исследовать предприятие с целью изучения и формализации его текущей и/или желаемой бизнес-модели
- Сравнить две бизнес-модели – заложенную в программный продукт и предприятия
- Определить разрывы, а затем выполнить проектирование новой функциональности и доработку программы
Другим вопросов является то, как дорабатывать. На своих первых проектах я относительно легко шел на изменение и даже полную переделку типового функционала и, в результате, получал много проблем в ходе дальнейшего обновления и сопровождения получившегося программного продукта (справедливости ради, нужно отметить, что, как правило, меня эти проблемы уже не касались – на поддержке я сижу редко и мало).
Сейчас я стараюсь планировать доработку “поверх” типового решения, путем “вписания” типовой функциональности в целевое решение, например, путем использования макродокументов – документов, которые сами не регистрируют хозяйственные операции, а управляют созданием и проведением набора типовых документов.
Такой подход тоже имеет свои недостатки, но, как показала практика, все равно он является более “экологичным” с точки зрения поддержки, обновления и развития программного продукта на базе типового решения.
Управленческий учет в 1C:ERP 2.4 и подготовка к Аттестации 1С:Специалист-Консультант.
Естественно бывают и другие случаи: когда на предприятии грамотно поставлен учет, не покрывающийся типовым функционалом. Насколько такой учет необходим предприятию – другой вопрос.
Согласен с Вами, и решения по такого рода вопросам и должны приниматься в ходе выполнения проектов по автоматизации
” если есть крупное предприятие/холдинг, которое долгое время ведет свою хозяйственную деятельность, значит, оно прибыльно или, как минимум, безубыточно”.
Но это может быть не благодаря существующему учету, а вопреки.
Очень много видел предприятий с разваленным учетом: не считается себестоимость, не идут остатки на складах, процветает воровство – тем не менее предприятие продолжает существовать.
Автор просто готов подстроится под каждого некомпетентного клиента.
Тезис был о том, что если предприятие прибыльно, то существуют внутренние и/или внешние факторы его деятельности, которые отличают его от других хозяйствующих субъектов на рынке, обеспечивают его конкурентоспособность и прибыльность. Данные факторы должны быть учтены при выполнении работ по автоматизации деятельности – проектировании, разработке и внедрении информационной системы, т.к. потеряв их, предприятие потеряет свою привлекательность для клиентов
Вы же фактически сказали “да, но…” и начали описывать проблемы, которые при этом могут иметь место быть. Обозначенные Вами вопросы действительно могут присутствовать на любом предприятии (в т.ч. и прибыльном) и внедрением информационной системы решены они не будут. В зависимости от ситуации, может потребоваться реорганизация системы учета и/или операционного управления, переосмысление стратегии развития организации и может быть привлечения правоохранительных органов
Э-э-э!?
В статье был ответ Сергея Гулакова?
Да, это мой ответ
И это не статья, а ответ на конкретный вопрос в мастер-группе
“Исследовать предприятие с целью изучения и формализации его текущей и/или ЖЕЛАЕМОЙ бизнес-модели”.
То есть, приходилось дорабатывать не только программный продукт, но и логику управления предприятием? Объяснять людям, что еще не все у них делается правильно, что нужно перестраивать свою работу или даже свое отношение к ней?
По Вашему мнению, какую часть из общих затрат своих душевных сил, физического времени, психического здоровья пришлось потратить на решение этой задачи?
То есть, приходилось дорабатывать не только программный продукт, но и логику управления предприятием? Объяснять людям, что еще не все у них делается правильно, что нужно перестраивать свою работу или даже свое отношение к ней?
Да, все верно. Можно сказать, что проект внедрения информационной системы на крупном предприятии или в холдинге – это только отчасти информационный консалтинг; также, он может включать в себя другие части, включающие управленческий/организационный консалтинг, финансовый/бухгалтерский консалтинг и другие виды консалтинговых услуг. Какие части и в какой пропорции он будет включать – зависит от целей и задач, которые ставят собственники и/или руководство предприятия, начиная проект
В целом же, можно сказать, что внедрение информационной системы такого класса как 1С:ERP – это хороший повод “перетрясти” всю систему управления и учета в целом
По Вашему мнению, какую часть из общих затрат своих душевных сил, физического времени, психического здоровья пришлось потратить на решение этой задачи?
Все зависит от конкретного проекта. В целом же хочу сказать, что на данные вопросы необходимо рассматривать именно как задачи, т.е. вопросы, возникающие при реализации проекта, которые потенциально могут быть решены. В этом случае и “затраты”, начинаешь уже воспринимать не как затраты, а как инвестиции, которые приближают светлое будущее :)
“данные вопросы необходимо рассматривать именно как задачи, т.е. вопросы, возникающие при реализации проекта”
То есть, проект уже готов и утвержден? В разработке проекта участвовали один-два представителя заказчика с правом совещательного голоса или привлекались руководители подразделений с их нуждами/пожеланиями/требованиями/ультиматумами? Далеко не все из 1000+ сотрудников понимают возможную пользу от внедрения новой технологии управления, многие этого побаиваются, а некоторые откровенно не хотят, потому что порядок отсекает возможности списать на текущий беспорядок свою лень, безответственность, теневые схемы доходов…
Как удается решить эти вопросы на стадии разработки проекта?
Коллега, Вы поднимаете слишком многоплановые и сложные вопросы для того, чтобы на них можно было дать однозначные ответы в ходе обсуждения на форуме
Безусловно, все отмеченное Вами имеет место быть на проектах внедрения – но это уже вопрос договоренностей/обсуждения/принуждения в ходе реализации проекта
На стадии проектирования же, обсуждается и утверждается целевой концепт будущей системы, который, как правило, согласуется с ключевыми пользователями, руководителями функциональных групп, а также руководителем/куратором проекта в целом
Добрый день!
Макродокументы – очень интересное решение, однако оно доступно только на последних версиях платформы, в которых можно создавать собственные документы в расширении? Не все типовые конфигурации тестировались на таких версиях платформы, значит придется ждать такой возможности?
Вот о чем я пытался сказать, при ответе на вопрос:
а.Необходимо по-минимуму снимать с поддержки типовые документы;
б.Необходимо искать варианты, при котором бизнес-процесс или отдельная хозяйственная операция описывается через совокупность типовых документов прикладного решения;
в.При этом, допустима ситуация, когда мы разрабатываем новый документ (который не является типовым и, поэтому, не будет затронут при обновлении на новый релиз), который обеспечивает управление созданием, заполнением и проведение типовых документов из одной точки ввода данных – тем самым облегчая пользователю использование прикладного решения
Возможности расширений не отменяют данный подход, а являются дополнительным техническим способом его реализации
Будет ли удачным такой подход: создать отдельную конфигурацию, содержащую только необходимые дополнения к типовой? Настроить обмен с рабочей базой на типовой конфигурации. В таком случае доработки находятся отдельно и обеспечивают необходимый дополнительный функционал, не затрагивая типовую конфигурацию.
Я бы не стал рекомендовать такой подход – само по себе создание такой конфигурации вполне себе решаемая задача, но что Вы будете делать с данными?
Регулярно передавать их между конфигурациями? Можно, но это очередные настройки и написание правил обмена – в общем, на мой взгляд, конструкция становится слишком сложной и неработоспособной