Насколько важно обследование предприятия?

klovsky | 03.09.06 | #
Один мой знакомый внедренец утверждает, что такая экпертиза не обязательна. Хотелось бы услышать еще мнения специалистов, насколько необходимо обследовать предприятие перед началом проекта внедрения системы автоматизации предприятия?

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

Кто и как должен его проводить?
Ответы
VSS | 04.09.06 | #
klovsky
Один мой знакомый внедренец утверждает, что такая экпертиза не обязательна. Хотелось бы услышать еще мнения специалистов, насколько необходимо обследовать предприятие перед началом проекта внедрения системы автоматизации предприятия?

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

Кто и как должен его проводить?

Исходя из того, что каждое предприятие (особенно промышленное) имеет свою специфику, предпроектное обследование необходимо. Иначе откуда проектант будет знать как построены бизнес-процессы, какие системы кодирования данных используются, как распределены функции между подразделениями, какие методы планирования, учета, регулирования используются и т.д. Мало вероятно, что серьезное предприятие будет полностью "прогибаться" под вашу систему. Это процесс взаимный.
Хотя есть в этом деле и исключения: отделения сбербанка, отделения связи, макдоналс, налоговая инспекция, ГАИ и т.п. У них практически типовые бизнес-процессы. И если есть готовое решение, то вполне возможно, что обследование - пустая трата времени.
Дмитрий | 04.09.06 | #
Насколько я знаю, бизнес аналитик не нужен только в одном случае:
- Число работающих в системе не более 5-7 человек.
- ВСЕ они являются высококлассными специалистами в своей области.
- Все имееют высокий уровень навыков работы с различными приложениями.
- Высокий уровень мотивации внедрения системы для ВСЕХ сотрудников.
В этом случае можно обойтись без аналитика.

Проводить обследование предприятия может как консалтинговая компания так и компания которая продает ERP систему, выбрать можно как тех так и других.

Чтобы обследование не проводить дважды , у обследования должен быть какой нибудь результат типа Технического Задания составленое в соответствии с ГОСТом.
Brasileiro | 04.09.06 | #
- Число работающих в системе не более 5-7 человек.
- ВСЕ они являются высококлассными специалистами в своей области.
- Все имееют высокий уровень навыков работы с различными приложениями.
- Высокий уровень мотивации внедрения системы для ВСЕХ сотрудников.

Еще забыли что на предприятии есть супер-мозг, который руководит внедрением всех подразделений, знает систему отлично и может решить проблемы взаимодействия подразделений в процессе внедрения (все они равномерно развиваться в новой системе не могут). В этом случае на предприятии может быть и больше 5-7 человек.
Guest | 04.09.06 | #
Дмитрий
Насколько я знаю, бизнес аналитик не нужен только в одном случае:
- Число работающих в системе не более 5-7 человек.
- ВСЕ они являются высококлассными специалистами в своей области.
- Все имееют высокий уровень навыков работы с различными приложениями.
- Высокий уровень мотивации внедрения системы для ВСЕХ сотрудников.
В этом случае можно обойтись без аналитика.

Обследование например не нужно, когда проект - автоматизация только бухгалтерии. В этом случае достаточно телефонного собеседования с главбухом . Бухгалтерия с точки зрения автоматизации - не сложно, если у внедренцев есть опыт.
mac2000 | 17.10.06 | #
одним из способов обследования есть анкетирование...

хотел поинтересоватся где можно почитать о них, их составлении и примерах?
MVA | 06.02.07 | #
Brasileiro
Еще забыли что на предприятии есть супер-мозг, который руководит внедрением всех подразделений, знает систему отлично и может решить проблемы взаимодействия подразделений в процессе внедрения


Это конечно хорошо, но для очень большого количества предприятий, особенно средних (хотя количество рабочих мест в системе может достигать более 30-50), супер-мозг - это утопия.
Часто нет даже серьеного координирующего органа.
Но обследование и разработка ТЗ - обязательно, если на предприятии хотят получить что-то путное в конкретный срок за конкретные деньги.
Основываясь на нашем опыте могу сказать, что обследование предприятия перед внедрением ОБЯЗАТЕЛЬНО. Мало того, практика показывает, что часто приходится разрабатывать новые методологии работы предприятия, поскольку даже такая "простая" область - бухгалтерия, зачастую ведется на предприятии неверно и внедрять автоматизированную систему в таких условиях просто аморально.

Для успешного внедрения автоматизированной системы необходима и экспертиза, и разработка методологии (или доработка, если она уже на предприятии существует, что опять же бывает исключительно редко).
SergAn | 16.02.07 | #
Expert
Обследование например не нужно, когда проект - автоматизация только бухгалтерии. В этом случае достаточно телефонного собеседования с главбухом . Бухгалтерия с точки зрения автоматизации - не сложно, если у внедренцев есть опыт

Ну это смотря какая бухгалтерия, и какая задача. Если просто проводкт колотить, то может быть. А если подходить как положено, с регламетацией статей затрат, правил расчета себестоимости и порядка закрытия счетов да еще на группе компаний, то без обследования и дальней разработки методики ведения учета нельзя. Вообще с системой как с болезнью: хочешь вылечиться - проведи обследование
Юрий | 27.02.07 | #
Добрый день, klovsky
Судя по утверждению ваш "внедренец" бывший программист или что-то около.
Прежде чем лечить, ставят диагноз.
ES | 27.02.07 | #
Юрий
Судя по утверждению ваш "внедренец" бывший программист или что-то около.
Прежде чем лечить, ставят диагноз.


Уважаемый Юрий, данный совет давал внедренец (может быть даже Внедренец), но внедренец ПО типа 1 ЦЕ 7.7. (или аналогичные коробочные решения). Т.е., внедрение затрагивает только БУ (НУ) и ничего более (при этом ВНЕДРЕНИЕ НЕ КАСАЕТСЯ, например, автоматизации таких задач, как внутренняя отчетность, отчетность по нулевой ставке ...) - т.е.:
SergAn
Если просто проводкт колотить, то может быть


В этом случае Внедренец может "запустить" за 2-3 недели и производственное предприятие (сразу оговорюсь - с некоторыми ограничениями).

При автоматизации предприятия присоединяюсь к сообществу: анализ обязателен!
busker | 28.02.07 | #
Т.е., внедрение затрагивает только БУ (НУ) и ничего более

В этом случае Внедренец может "запустить" за 2-3 недели и производственное предприятие (сразу оговорюсь - с некоторыми ограничениями).


Тут мне не понятно, что он будет делать 2-3 недели?
Юрий | 28.02.07 | #
Бу за 2-3 недели это возможно но сбольшими ограничениями.
ES | 28.02.07 | #
busker
Тут мне не понятно, что он будет делать 2-3 недели?


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

Вы считаете что 2-3 недели для производственного предприятия (не ларька) это много?
busker | 01.03.07 | #
ES

Для начальных остатков (если они есть) и аналитики - много.

Тут есть еще вопрос - Что при этом получает производственное предприятие?
Чем "коробка" 1С-Бухгалтерии в этом случае будет отличаться от такой "автоматизации"?
Юрий | 01.03.07 | #
К сожалению наша дискуссия сильно отклонилась от главной темы этого разговора. Я остаюсь при своём мнении ни Ахапта ни Навижн ни САП ни подходят к машиностроению в моём понимании потребностей предприятий по автоматизации, так как они изначально логически и процессно "затачивались" под автоматизацию финансового блока.
ES | 01.03.07 | #
Согласен, Юрий, для этой ветки - это действительно сильное отклонение от темы.
Убеждать Вас стать адептом MBS, SAP ... я и не собираюсь. Вы привели свой пример, я свой. Все остальные могут делать выводы, спрашивать, если интересно. Одна из целей форума - получать и делиться информацией.
Юрий | 01.03.07 | #
Адаптом SAP не стану потому, что сейчас веду проект САПа.
ES | 01.03.07 | #
busker
Для начальных остатков (если они есть) и аналитики - много.


Уважаемый busker, я привел перечень работ (кстати, не весь), среди которых часть времени занимает закачка. То, что предоставляет заказчик и в каком виде - это отдельная песня.

busker
Тут есть еще вопрос - Что при этом получает производственное предприятие?


Реализацию своих потребностей при использовании данного продукта.

busker
Чем "коробка" 1С-Бухгалтерии в этом случае будет отличаться от такой "автоматизации"?


Примерно тем же, чем ларек отличается от предприятия.

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

А теперь переложите все это на "коробку"

Но продолжение этой темы - отдельная дискуссия.
ES | 01.03.07 | #
Юрий,

внедрите пож. А то получится решение равнозначное правилам правописанию. И здесь, действительно, вспомнится "Уникак". Сорри за колкость.
Юрий | 01.03.07 | #
Моя "грамотность" это в компаниях притча во языцах. Ещё в школе учитель по "русскому" махнул на меня, со словами "...врождённая не грамотность.."
busker | 02.03.07 | #
Вы видели когда-нибудь "коробочные" планы счетов?
Вы работали с этими планами счетов на предприятиях различного масштаба и отраслей?
Вы сталкивались с ситуациями, когда в плане счетов объединяются требования бухгалтеров, экономистов, менеджеров, диспетчеров, управленцев ...?


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

И представьте себе, что бухгалтеры огромных предприятий работают на "коробочной" 1С и их это вполне устраивает. А для экономистов, менеджеров и т.д. и т.п. - нужны свои регистры учета (системы, модули). И не нужно ссылаться на ларек. С точки зрения бух учета - что ларек, что монстр - проблемы одинаковые. Объемы только разные.
ES | 02.03.07 | #
Вы не ответили на вопросы.

busker
"Коробочные" планы счетов выполняют вполне конкретную задачу


Какую, если не секрет? У разных предприятий задачи разные. Кстати, здесь опять возникают заданные ранее мною вопросы.

busker
Зачем бухгалтерии аналитика менеджера или тем более диспетчера?
Зачем ее пихать в план счетов?


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

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


Какие?

Я, надеюсь, ошибаюсь в своем предположении, что БОСС-Компания при внедрении на различных предприятиях ТОЛЬКО БУ использует коробочный план счетов?

Практическое внедрение коробок, как я уже писал - отдельная дискуссия. Форум ERP.

Если хотите - откройте новую тему. А так же, если хотите, могу предложить Вам решить, без доработок и настроек, на коробке чисто бухгалтерскую задачку. :?
busker | 05.03.07 | #
ES

Не знаю, зачем Вам ответы на эти вопросы, но раз уж настаиваете:

Вы видели когда-нибудь "коробочные" планы счетов?


Да. В разных системах. Но в этой ветке говорю только об одной коробке - 1С.

Вы работали с этими планами счетов на предприятиях различного масштаба и отраслей?


Да работал. Мало того, у меня много знакомых бухгалтеров, которые работают с 1С на различных предприятиях.

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


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

busker писал(а):
"Коробочные" планы счетов выполняют вполне конкретную задачу


Какую, если не секрет? У разных предприятий задачи разные.


"Коробочный" план счетов (1С) позволяет бухгалтеру внести данные в необходимом разрезе, провести необходимые расчеты и контроль для формирования основных бухгалтерских форм отчетности (балансы и т.п.).
И других зачач у бухгалтерского учета - нет.

busker писал(а):
С точки зрения бух учета - что ларек, что монстр - проблемы одинаковые


Какие?


И там, и там на бухгалтерию пытаются "навесить" несвойственные ей функции.

Я, надеюсь, ошибаюсь в своем предположении, что БОСС-Компания при внедрении на различных предприятиях ТОЛЬКО БУ использует коробочный план счетов?


Тут Вы ошибаетесь. Т.к. использовать БОСС-Компанию только для бухгалтерского учета не имеет смысла. Система предназначена для управления в первую очередь. И имеет для этого все необходимые регистры, чтобы не перегружать без необходимости бухгалтерский план счетов несвоиственной аналитикой. А логистическая часть системы позволяет реализовать практически любой оперативный учет.
Только зачем переходить на "конкретные продукты". Я же на спрашиваю у Вас - "когда Вы внедряете Ваше решение на "Axapta ТОЛЬКО БУ", тоже коробочный план счетов используете?"
Глупости какие-то...
ES | 06.03.07 | #
Мои вопросы касались практической стороны внедрения коробочных продуктов. Тот, кто занимался не внедрением, а Внедрением - меня поймут: внедренец инсталлирует продукт, а Внедренец реализует наиболее удобное решение для конкретного предприятия.
Более того, на коробочном плане счетов зачастую невозможно решить даже чисто бухгалтерскую ф-цию по формированию себестоимости без модификации плана счетов и аналитических разрезов (например, турбизнес, деятельность АТП и экспедирование, ВЭД - перевалка грузов, сертификация, перевозка ...). А как автоматизтровать аналитический учет ЗП, налогов по проектам когда, например, один человек работает на нескольких проектах и т.п.) в коробочном продукте 1С? При инсталляции можно вести учет на "коленке" загружая бухгалтерию свойственными ей функциями, а при Внедрении и автоматизации значительно экономим время. Да, коробочный продукт не решит все задачи предприятия, но облегчить жизнь при грамотном внедрении может.
И задача бухгалтеррии отнюдь не в формировании отчетности - это итоговая часть реализации БУ (которая, кстати ), который на предприятии должен быть организован. настроен и максимально автоматизирован на ПО.
Исходя из того, что все это это время я выражаю свое несогласие с достаточностью коробочного плана счетов для ведения БУ на различных предприятий, Ваш вопрос о использовании коробочного плана счетов при внедрении на Axapta по крайней мере странен. Даже при внедрении коробок он используется как отправная точка.

Ошибаюсь в чем? В том, что при внедрении Вы используете коробочный план счетов?
Тогда мне непонятна Ваша позиция относительно его применимости для предприятий различных видов деятельности.
busker | 12.03.07 | #
ES
Поскольку общение перешло в стадию "разговора слепого с глухим", и не несет какой-то положительной информации остальным - предлагаю не углубляться в нюансы наших противоположных мнений.
ImpCons | 25.04.07 | #
Считаю, что и для средних/крупных внедрений, если целью предпроекта не является определение точных сроков, задач, бюджета проекта, - то можно в некоторых случаях и обойтись и без него.

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

Если клиент готов заключить контракт на почасовую оплату всего проекта внедрения или хотя бы этапа моделирования (создания модели TO BE и прототипа системы), то можно обойтись без предпроекта. После этапа моделирования, все то же что было бы сделано на проедпроекте более точно можно получить.

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

Но боюсь клиент вряд ли на такие сценарии проведения внедрения подпишется, потому как, - ему проще получить предпроект от внедренческой компании за небольшие, в сравнении со всей стоимостью проекта, деньги и уже зная бюджет проекта, принимать решение о внедрении или отказе.
Biker | 02.10.07 | #
Обследование объекта не просто обязательно, оно НЕОБХОДИМО, т.е. без него не представить, какие документоопотоки и как движутся на данном предприятии. Если учитывать, что ГОСТы по документообороту и пр. носят во многом рекомендательный характер, то, соответственно, учет документов и пр. может сильно разниться.

Резюме: без ПОЛНОГО ОБСЛЕДОВАНИЯ объекта внедрения систем документооборота сам процесс внедрения в принципе не возможен, т.е. много моментов придется переделывать по несколько раз, что в конечном итоге загубит все внедрение на корню...
А как вы считаете, нужно ли обследование предприятия, даже если потом не внедрять СЭД?
Ведь время идет, законодательство меняется, делопроизводственные процессы тоже... Мне кажется, обследование нужно предприятию. Так руководство сможет узнать, рационально или нет проводятся те или иные операции с документами, может, что-то уже пора менять...
Интересно услышать и другие мнения :)
Guest | 26.02.09 | #
Если мы говорим о коробочном ПО, особенно "популярном" - то по-другому просто не получится. Нужны отчеты/обследования/ТЗ/ЧТЗ/спецификации и т.д. просто чтоб прикрыть задницы участникам проекта. Если мы говорим об обследовании с целью создать новое ПО - вот отличный путь http://gettingreal.37signals.com/toc.php Если мы говорим о консалтинге "вообще" - это всё только ради отката.
Stanislav Kim | 28.09.09 | #
klovsky
Один мой знакомый внедренец утверждает, что такая экпертиза не обязательна. Хотелось бы услышать еще мнения специалистов, насколько необходимо обследовать предприятие перед началом проекта внедрения системы автоматизации предприятия?
Каким должно быть обследование, чтобы при внедрении дважды не наступать на грабли?
Кто и как должен его проводить?


Ваш знакомый внедренец привык "натягивать" клиента на СЭД без кастомизации, утверждая, что все лучшие кейсы уже реализованы в системе. Клиент идет на поводу, делает как все и какое конкурентное преимущество он получает? Никакого.

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

В нашей компании обследование и постановка задач обязательны в проектах любого размера, кроме вариантов когда заказчик просто покупает лицензию, предпочтя разобраться самостоятельно. Иначе будет реализовано не то, что клиенту надо и потом никто никому ничего не докажет.
Alex Smirnov | 29.09.09 | #
Полностью согласен с предыдущим постом, с той лишь оговоркой, что можно обойтись без громкого названия ОБСЛЕДОВАНИЕ ПРЕДПРИЯТИЯ.
Обчно, в календарном плане есть строчка "Разработка ТЗ" (или несколько строчек если нужно спланировать несколько интервью или несколько итераций в зависимости от масштаба).
Сама активность - анализ и проектирование, это постоянный процесс, с активной фазой в начале проекта.
Максфилл | 12.03.10 | #
В каждом внедрении системы документооборота должно быть разработано и согласовано Техническое задание. Это нужно и исполнителю и заказчику. Иначе конфликтов не избежать!
Обследование позволяет выявить не только требования, но и потенциальные риски проекта. Кроме того, важно не только учесть требования, но и сопоставить их с ожиданиями заказчика.
Необходимо так же фиксировать и изменения требований. При сдаче-приёмке работ фиксируем в ведомости результат испытаний по каждому требованию.
Однако, не стОит полностью полагаться на ТЗ. У меня был случай, когда заказчик сказал, что : "да, мол, мы забыли включить это требование в ТЗ. Мы виноваты, но и вы виноваты! Мы же вас пригласили как специалистов! Вы должны были нам на это указать при обследовании!"
Заказчик подразумевал некоторую функциональность системы, но она нигде не была описана или упомянута. Портить отношения с заказчиком? Нет, конечно. Только поиск компромиссного решения...
Хорошо, что было ТЗ! А без него бы нам пришлось бесплатно дорабатывать систему.
Наличие в проекте согласованного ТЗ и процедуры корректировки требований, позволяет снизить риски и конфликты. Объясняйте это заказчику. Его ожидания от внедрения могут сильно отличаться от того, что он Вам говорит.
Ищите обход подводных камней пока находитесь на берегу.
И ещё одна рекомендация: фиксируйте и публикуйте все успешные события (этапы, вехи)проекта, потому что одно мрачное событие может затемнить все ваши предыдущие успехи.
Слишком разное содержание вкладывают в это понятие- обследование. Прежде чем его проводить, нужно понимать:
-для каких целей оно проводится;
-что именно нужно описать;
-как результаты обследования повлияют на итоги проекта, на разрабатываемую или внедряемую систему.
Вообще говоря, нужно согласовывать методику обследования, методику интерпретации результатов.
Иначе отчет по обследованию - кот в мешке, и он всегда не такой, какой ожидали.
Проблема еще в том, что обследование затягивает время проекта. Начинаешь описывать - затягивает, хочется описать подробно, провести анализ,посоветовать улучшения, а за это время случается что-нибудь непредвиденное, все меняется, и...начинай сначала.
Обследование должно быть, но что-то типа блиц, только необходимое для начала работы. А внедряемая система должна обладать свойством быстрой перенастройки, имодифицировать процессы нужно по ходу дела. Только тогда можно реально что-то внедрить.
Sergiy | 20.04.10 | #
Начинаешь описывать - затягивает, хочется описать подробно, провести анализ,посоветовать улучшения, а за это время случается что-нибудь непредвиденное, все меняется, и...начинай сначала.


Согласен с каждым словом. Неоднократно натыкался на такие ситуации...
но спасало как раз то, что сказано Ольгой ниже... А именно "система должна обладать свойством быстрой перенастройки"...
Podkorytova | 27.09.10 | #
klovsky
Один мой знакомый внедренец утверждает, что такая экпертиза не обязательна. Хотелось бы услышать еще мнения специалистов, насколько необходимо обследовать предприятие перед началом проекта внедрения системы автоматизации предприятия?

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

Кто и как должен его проводить?


Не согласна с мнением Вашего знакомого. Поверьте на слово, как руководителю проекта внедрения СЭД «DIRECTUM» со стороны заказчика. Какой бы замечательной не была система электронного документооборота, без качественного обследования предприятия она будет всего лишь программой для хранения и регистрации электронных документов. Более того, перед обследование необходимо разработать политику в области управления документами (см.ГОСТ Р ИСО 15489-1- 2007 НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ Система стандартов по информации, библиотечному и издательскому делу. Управление документами. Общие требования. А обследование необходимо для корректировки существующих процедур работы с документами и исключения риска «дважды наступить на грабли». Проводить обследование должны квалифицированные консультанты предприятия-внедренца или сторонние аудиторы.