Есть 2 подхода к внедрению информационных систем. На примере 1С УПП 8

26.01.12

С детальным ТЗ? Или без серьезного ТЗ? Какой лучше? И где успех более вероятен?

Варианты такие:

с подготовкой, детальным описанием ТЗ, с минимизацией рисков, но с очень большой задержкой на этапе подготовки (и очень дорогой);
без серьезной подготовки, с общим ТЗ, встречая проблемы по мере выявления;

Причем нельзя сказать какой подход лучше. Все зависит от ситуации. В соответствии со стратагемой №2. Рассмотрим подробней…

Если задача уникальна, то конечно же п.1 — выгоднее.

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

Взять один из самых сложных продуктов: 1С УПП 8. Можно ли эту задачу назвать уникальной? Для той организации, где начинается внедрение — безусловно да.

Но вопрос не в организации, а вообще, касательно данного типа проектов.

На самом деле это достаточно определенная задача, и если смотреть достаточно абстрактно, то очень даже ясная.

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

Если когда-то эти функции легко выполняли 30 бухгалтеров, на бумаге, то неужто ПО уровня 1С УПП 8 — не сможет выполнить эти функции в типовой версии?

Так какой путь выбрать при внедрении 1С УПП 8? 😀 В 99% проектов внедрения нужно выбирать п.2 — без подготовки, с общим ТЗ. С закреплением общих для всех организаций целей.

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

Допуск программистов к ПО до завершения проекта внедрения — это смертный приговор проекту, с минимальным шансами на выживание и успешное завершение. Даже, если при этом будет прописано очень детальное и дорогое ТЗ, на листов так 200-300.

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

Источник: http://itau.ru/blog/2012/01/26/est-2-podhoda-k-vnedreniyu-informatsionnyih-sistem-na-primere-1s-upp-8/

+14 –2

См. также

Моделирование требований. Requirements Modeling Language (RML)

Работа с требованиями Работа с заинтересованными сторонами Анализ потребностей и поиск решений Бесплатно (free)

Requirements Modeling Language (RML) - язык, разработанный специально для визуального моделирования требований. При разработке RML существующие модели были модифицированы для упрощения восприятия информации заинтересованными сторонами. В RML используются только простые и интуитивно понятные символы.

12.12.2024 466 0 SerjoginaMaria 5

Собственный опыт недавнего поиска работы и первого внедрения ЕРП

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

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

04.12.2024 1051 0 bolikov 21

Внедрение 1С ERP на крупном предприятии, переход с 1С УПП

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

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

29.10.2024 797 0 VicCva 1

Анализ результатов опроса заказчиков, внедрявших 1С ERP

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

Мы провели опрос заказчиков с целью определить степень удовлетворенности внедрением 1С: ERP. Опрос проводился по случайной выборке из списка внедренных решений на сайте 1С. Обработали 121 интервью от 97 компаний. Из выборки мы исключали "показательные внедрения" и крупнейшие холдинги, старались получить срез по "средним" массовым заказчикам. Статья будет интересна сотрудникам отделов продаж и отделов качества фирм, внедряющих 1С, потенциальным заказчикам и всем, кто интересуется статистикой внедрения 1С: ERP. Текст статьи довольно большой, в некоторой степени наукообразный.

16.10.2024 1578 0 Soliton 8

Разработка и внедрение в новой реальности: можете не меняться. Выживание не является обязанностью

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

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

13.09.2024 2634 0 glebushka 5

Семь шагов обследования (к завоеванию мира) к построению успешной ИТ-системы

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

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

02.09.2024 1410 0 user1669221 2

Документация по ГОСТ – не только ТЗ

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

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

21.08.2024 2941 56 Laya 3

Оценка проекта: угадываем будущее

Анализ предметной области Анализ потребностей и поиск решений Бизнес-аналитик Руководитель проекта Управленческий учет Бесплатно (free)

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

19.08.2024 1751 0 SergeyN 0

Отзывы

11. elkis 01.02.12 15:56 Сейчас в теме

Согласна с Максимом Сейчас вытаскиваю как раз такой проект, до меня внедренец обещал золотые горы (без ТЗ!), и сбежал с проекта А клиент с сознанием того, что делать ничего не придётся, а внедренцы всё настроят, теперь загибает пальцы А я кляну их всех и пытаюсь сделать из г... конфетку. А если бы было ТЗ! А если бы юзеров обучили! А если бы документация велась! И много ещё всяких если Поэтому однозначно - подход №1

20. Raminus 07.02.12 12:21 Сейчас в теме

(1) Арчибальд, сейчас находимся как раз на выборе варианта подхода, склонялись к №1 прочитал, спасибо Арчибальд, задумался, а стоит ли.

Остальные комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. Арчибальд 2709 27.01.12 09:16 Сейчас в теме

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

2. 27.01.12 09:25 Сейчас в теме

(1) Арчибальд, держись-крепись, мы мысленно с тобой ))

20. Raminus 07.02.12 12:21 Сейчас в теме

3. syncmas 27.01.12 09:31 Сейчас в теме

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

4. _smile_ 27.01.12 09:59 Сейчас в теме

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

5. kolga 01.02.12 08:51 Сейчас в теме

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

6. Максим2 9 01.02.12 10:19 Сейчас в теме

"встречая проблемы по мере выявления"
вот эта стадия выявления проблем видимо делается на тестовой базе с примером. На практике постоянно возникают сложности, когда делается переход на новую конфигурацию, то предлагаю пользователям воспроизвести свою работу (менеджер по продажам, бухгалтер и т.д.) на демо-базе, чтобы вопросы решить заранее. И практически всегда не находят на это время. Только когда переход на новую программу произошел, тогда начинают сыпаться вопросы и выявляться проблемы. Т.е. как метод обучения плаванию: бросить в воду и тут уже никуда не деться, надо плыть. А научиться сначала плавать, а потом собственно плыть - можно сказать, что крайне редко это удается.
Хотелось бы услышать мнения по этому вопросу, как сделать переход со старой системы/внедрение более плавным. Теоретически то все понятно, что надо изучить сначала пользователям новую программу, но...

7. 01.02.12 10:33 Сейчас в теме

(6)

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

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

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

8. novosys 01.02.12 13:13 Сейчас в теме

Категорически не согласен с автором! Более того, скажу, что этот самый второй вариант отражает славянский менталитет: на авось и соваться в воду не зная броду! Чтобы нормально внедрить УПП, нужно нормально провести все этапы: обследование, интервью, постановку ТЗ и, собственно, реализацию. Понятно, что по ходу внедрения могут вноситься коррективы в ТЗ. Но должен быть проработан план внедрения, нужно ясно представлять все бизнес-процессы на предприятии (не надо рассказывать про то, что в УПП почти всё реализовано и любой бизнес можно подогнать под базовый функционал - это неправда!), чтобы иметь представление о том, что внедряется как есть, а что требует доработок. Не зная этого, вы элементарно не сможете назвать заказчику стоимость проекта.

9. Максим2 9 01.02.12 13:49 Сейчас в теме

(8) novosys,
Приходиться сталкиваться с тем, что "нормально" провести обследование, интервью, постановку ТЗ также не получается, по причине пассивности пользователей, т.е. до самого внедрения и запуска. И по ходу внедрения коррективы в ТЗ не то, что МОГУТ вноситься, а почти гарантированно вносятся, причем достаточно много и серьезные.
Так вот, подход сначала с общим ТЗ, встречая проблемы по мере их выявления, приводит к включению пользователей в процесс внедрения уже в ходе его осуществления.
По поводу оценки стоимости проекта, согласен, есть наверное такая проблема, потому как непонятно, сколько вылезет проблем и какого масштаба. Наверное тут просто задача правильно просчитать порядок суммы и попасть в него.

10. 01.02.12 14:54 Сейчас в теме

(8)

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

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

15. novosys 02.02.12 23:16 Сейчас в теме

(10)
А разве для налоговой отчетности и ПБУ необхадимо внедрять УПП?! Для этих целей достаточно Бухгалтерии. А УПП обычно внедряют, преследуя несколько более масштабные цели. И примеров - мильйон! Только думаю, что засорять тему примерами из моей практики - это неправильно. Если интересно - могу Вам лично привести, и даже буду безмерно благодарен (без сарказма), если Вы покажете мне способ реализовать их в УПП без доработок.

17. 07.02.12 11:13 Сейчас в теме

И примеров - мильйон! Только думаю, что засорять тему примерами из моей практики - это неправильно.

(15)
я не прошу мильоном комменты засорять. один приведите, чтобы мне вас за балобола не считать и понимать есть ли смысл вообще тратить время на ответы по вашим комментариям.

(16) Арчи, это жульничество!!! )) я спорил лишь в части УПП. понятно что БП умеет считать затраты в общем, тем более что ты привел проектную организацию, а проектный учет и РАУЗ появляется в типовых версиях начиная с КА.
я так не играю.

19. Арчибальд 2709 07.02.12 12:05 Сейчас в теме

(17) Нет, это не жульничество. Я привел пример того, что жизнь богаче, чем представление о ней разработчиков типовух. Кстати, ту схему учета тоже (в принципе) загнать в УПП, учитывая основную деятельность на 20 счете вместо 26. Но расчет себестоимости допиливать придется - скажем, регламентную внешнюю обработку прикрутить.
Вот сейчас пытался еще найти обсуждение того, какие трудности создает УПП, если производство не сборочное, а разборочное. Не нашел пока...

21. 07.02.12 12:29 Сейчас в теме

(19) хочешь сказать, что запустить в этой организации УПП без программистов было бы не реально?
в части основных требований учета, подготовки отчетов по налогам, базовых отчетов и т д.

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

22. Арчибальд 2709 07.02.12 13:03 Сейчас в теме

(21) Нет, скорее прав, чем неправ. Использовать типовой потенциал следует по максимуму, возможно, даже подгоняя под него некритичные "заморочки". И уж когда конкретно выяснится, что чего-то нет, а без него - ну никак, тогда допил. Но прежде чем допиливать, нужно конкретно на бумаге сформулировать, чего именно не хватает. ТЗ на доработку с указанием причин принятых решений.

51. tango 546 17.09.13 11:34 Сейчас в теме

(17)

один приведите, чтобы мне вас за балобола не считать

угадайте с одного раза, за кого можно принять тс с его "принципиальной" позицией non-tz

16. Арчибальд 2709 07.02.12 10:49 Сейчас в теме

(10)

пример в студию...

http://infostart.ru/public/98891/ ;)

11. elkis 01.02.12 15:56 Сейчас в теме

12. 01.02.12 16:13 Сейчас в теме

(11) elkis,

Согласна с Максимом Сейчас вытаскиваю как раз такой проект, до меня внедренец обещал золотые горы (без ТЗ!)

речь не о без ТЗ. речь о том что детальные и дорогие ТЗ в части УПП это причина провалов. когда поставщик делает упор на программирование, вместо внедрения.

ТЗ нужно в любых проектах.
Я например в ТЗ пишу список процессов от которого и делаю рассчет цены. Туда входит описание инструкций, настройка типового функционала, обучение по описанным инструкциям (а не просто семинары и теория).
Это классика любого внедрения.
Но именно разработку исключаю, выношу за проект. И в этом случае ТЗ получается очень легким. На 10 страниц позаглаза. И обследование это занимает 1 день на анкету и пару дней на уточнение подозрительных моментов. Все! 90% рисков закрываются.

13. elkis 01.02.12 17:28 Сейчас в теме

:) Истина где-то посередине Я вообще-то против ТЗ на 2х страницах Как раз сейчас по такому работаю (до меня внедренец такое ТЗ согласовал) Доказать что-либо по такой бумаге сложно В результате - как стричь свиней, визгу много, шерсти мало Риски при внедрении УПП просто огромные Боюсь вообще ничего не получить, кроме повышения собственной самооценки

14. Foxx 110 02.02.12 03:51 Сейчас в теме

Работу ранее выполняли люди на бумаге (старом ПО, не суть важно), с появлением нового ПО (допустим, УПП) - работу выполняют все те же люди. ПО - лишь инструмент. Лучше или хуже приспособленный (правильно/неправильно используемый) для решения задачи. И еще, в типовом варианте - конфигурация далеко не всегда "сможет выполнять те же функции".

18. 07.02.12 11:18 Сейчас в теме

И еще, в типовом варианте - конфигурация далеко не всегда "сможет выполнять те же функции".

(14)
это точно. на одном предприятии где мне пришлось внедрять ЗУП, переводить бухгалтеров в прямом смысле со счетов и бумажных журналов/рассчеток, их привычку округлять зарплату до 10 коппеек включая рассчеты для налоговой базы, с целью повышения удобства кассовых выплат - я не смог. Программа не умеет так хитро ) но решилось просто... объяснил бухгалтерам что округление налоговой базы до 10 копеек, даже ради благородной цели - повышения удобства кассовых выплат - нормативами не предусмотрено.
И как только учет подогнали под требования законов - опля и все пошло :) Без изменения ПО.
Вот такой вот фокус.

Ну и у меня просьба, давайте под свои слова приводить факты/примеры/аргументы. Чтобы не превращать комментарии в треп бабулек. А то мне скучно станет и я перестану отвечать :)

23. novosys 07.02.12 13:33 Сейчас в теме

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

24. 08.02.12 07:21 Сейчас в теме

(23)

правило IBM: думают люди, считают компьютеры.
ну или глянуть сюда http://infostart.ru/public/105038/
там это звучит так: «Человек должен предоставить данные, затребовать отчеты и провести анализ. Компьютер должен
Все сосчитать».

Что это означает к данному, конкретному примеру?
для начала давай разложим процедуру ценообразования на ключевые действия с точки зрения этого правила:
1. ввести данные - человек
2. сосчитать затраты - компьютер
3. предоставить отчеты о затратах - компьютер
4. проанализировать отчеты, обдумать и определить ценник на продукцию - человек
5. ввести данные о цене на продукцию - человек
6. сосчитать доход от продаж с учетом п.5 - компьютер

Ну и я говорю об общих требованиях, которые определены в законе - откаты сюда врятли подходят.

К тому же, давай тогда ставить задачи рассчета цен и условий при торговле наркотой, детской порнографии, с учетом отката киллерам за устранение не путевых конкурентов, а также услуги аутсорсинга типа этого http://xn--b1aaiabj4ag2cl.xn--p1ai/

Это ты понимаешь как нормальный проект?

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

25. 08.02.12 07:27 Сейчас в теме

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

26. Ish_2 1113 13.02.12 00:16 Сейчас в теме

(25) Ты "уважать себя заставил" недавней "космогонной" статьей. Я стал придирчивей читать твом тексты.
В текущей статье , в основном общие рассуждалки, но одно утверждение обойти невозможно :

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

Категорично и безальтернативно. Впечатлительный Арчибальд уже начал поддакивать (22).

А я тебе говорю , Анатолий, ты предмета не знаешь и не понимаешь о чем пишешь.

Внедрение типовой УПП , а затем допиливание "хотелок" - это дико - редкое исключение, но никак не правило.
В подавляющем количестве случаев внедрение УПП невозможно без внедрения дополнительного функционала, разработанного некоторой фирмой. В 99% процентах случаях функционал допиливается на ходу , не только из-за нерадивости кодеров , но из-за меняющихся требований заказчика. Мы ведь работаем по твоему второму варианту
с размытой постановкой задачи. КОнечно, это плохо , но так есть.
Про это же тебе говорят в (15):

А разве для налоговой отчетности и ПБУ необхадимо внедрять УПП?! Для этих целей достаточно Бухгалтерии. А УПП обычно внедряют, преследуя несколько более масштабные цели. И примеров - мильйон! Только думаю, что засорять тему примерами из моей практики - это неправильно. Если интересно - могу Вам лично привести, и даже буду безмерно благодарен (без сарказма), если Вы покажете мне способ реализовать их в УПП без доработок

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

27. Арчибальд 2709 13.02.12 07:55 Сейчас в теме

(26) Во-первых, я поддакивал совершенно не тому. Я представил (ощутил) ситуацию, когда внедрение УПП (что само по себе суть ошибка) неизбежно. И в этом случае минимизацию неизбежного ущерба следует искать в направлении сохранения конфы.
Во-вторых, я не воспринял "допуск программистов" как эскападу, направленную против программистов. Хотя автор и в самом деле не дружит с программированием, он прекрасно понимает, что в здравом уме и трезвой памяти программист конфу менять не будет. Речь о хотельщиках в фирме-заказчике. Внедренец должен выяснить, в чьих интересах идет внедрение, кто сел на хвост и рулит, а потом послать и тех и других. Как-то так.

30. 13.02.12 13:21 Сейчас в теме

(26) Ish_2,

Внедрение типовой УПП , а затем допиливание "хотелок" - это дико - редкое исключение, но никак не правило.

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

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

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

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

31. Ish_2 1113 13.02.12 14:58 Сейчас в теме

(30)

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

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

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

В гостиничном комплексе внедряется УПП + Opera+ Micros (программный коплекс для гостиниц)
Внедряется и проверяется взаимодействие одновременно. В УПП - дополнительный функционал - это общепит + система интеграции с Opera-Micros. Это не всё, но уже достаточно.
Все внедряется и отлаживается
во взаимодействии с другими постащиками программного обеспечения - ОДНОВРЕМЕННО.

33. Арчибальд 2709 13.02.12 15:16 Сейчас в теме

(31) Общепит - это именно то, под что УПП писали. Чего ж там допиливать-то? :))
Суть твоего утверждения - невозможность внедрения без допиливания? Это явный бред, раздел "внедренные решения" на сайте 1С кишит такими внедрениями. Невозможность допиливания после внедрения? И вовсе бред, армия одноэсников тем в основном и живет.

36. Ish_2 1113 13.02.12 17:24 Сейчас в теме

(33) Зачем " бредом" обзываешься ?
Всё так и есть . Допиливание осуществляется "на ходу" . Я этим и занимаюсь , в том числе.

Вопрос даже не ставится: внедрим , а допилим потом. Оторвут голову.
Внедрять без допиливания НЕЧЕГО : Вся реализация и оплаты во внешних по отношению к 1с УПП системах.
Всё внедрим , все допилим на ходу - только так.
Почему бы тебе не поверить в жизнеспособность такого проекта ?

38. 13.02.12 19:38 Сейчас в теме

(36)

Почему бы тебе не поверить в жизнеспособность такого проекта ?

потому что все участники такого проекта должны быть верхом адекватности и компетентности, каждый в своем деле, при этом уметь не лезти в чужие дела слишком глубоко. А такого соотношения благоприятных условий я не видел.
А все проекты, подчеркиваю все проекты, которые пускались по этому пути... улетали в кювет, т.к. начинался не управляемый поток хотелок, который приводил к бюджетам уровня 1 млн.рублей/месяц, проект внедрения превращался в процесс внедрения, с растяжкой на годы, и система работала в режиме "все делаем ручками".
Опыт не позволяет мне поверить в эффективность такого подхода.
Под эффективностью я понимаю дою успешных проектов с этим подходом в реальных условиях.
т.е. берем 1С-Франчайзи, у которого за 3 года было около 50 проектов по 1С УПП 8 и вскрываем статистику.
Получаем что большая часть проектов в попе. Но никто этого в открытую не скажет :)
Я работал в крупном 1С Франче. Понимаю о чем говорю :)

41. Ish_2 1113 14.02.12 12:42 Сейчас в теме

(38) Почти всё так.
Но передразню - "Залатые слова" .
Осталась небольшая деталь :
Реализация и Оплата во внешних к 1с системах.
Внедрять УПП без интеграции с этими системами не имеет смысла.
99% проблем в этой самой интеграции. Начали внедрять и узнали много чего интересного про внешние продукты,
много чего ненаписанного в ТЗ.
Говорю тебе - возможность внедрения без программиста - это счастье. В этом с тобой никто не спорит.
Но много ты видел счастья на Родине ?

42. 14.02.12 15:04 Сейчас в теме

(41) Ish_2,

Реализация и Оплата во внешних к 1с системах.
Внедрять УПП без интеграции с этими системами не имеет смысла.

ты уверен в этом на 100%? ))

давай смотреть на ситуацию с точки зрения владельцев и высшего руководства.
Они мысля просто:
1. я не вижу план по прибыли, я не вижу фактическую прибыль в разрезах и динамиках, а мне это надо, потому что позволяет уверенно держать руль организации, подключать свои ресурсы
2. все что мне надо это информация! информация! и еще раз: ИНФОРМАЦИЯ!
3. это все для чего нужна 1С УПП 8 - этим ребятам
4. и тут ты такой... ребята внедрение 1С УПП 8 не имеет смысла если мы ее не интегрируем с каким нибудь там Интернет-банком.
5. он на тебя так глянет... ууу... и подумает... ты мальчик чего тут говоришь? да я вон бухгалтеров пачку куплю и они эти две системы заинтегрируют лучше тебя в 2 раза. и по цене это будет копейки в сравнении с потерями которые они терпят из за отсутствия информации...

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

Руководству на самом деле пофигу на автоматизацию. Если надо, они еще 2 или 3 или пачку бухов купят. При оборотах в миллионы рублей в месяц, 1 или 2 буха - это копейки. А вот информация - это действительно то что ценно, и это то ради чего руководители готовы тратить деньги на внедрение. И эту информацию можно получиь без интеграции. А интеграция на ее получение никак не влияет. Это вообще не ИТ, а КТ т.е. компьютерная технология, которая на сбор информации влияет очень и очень слабо. Разве что чуть от ошибок защищает, но они по факту не критичны.

28. novosys 13.02.12 12:31 Сейчас в теме

(25)

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

29. 13.02.12 13:12 Сейчас в теме

(28) novosys, да нету у меня белых и пушистых. Просто плохим танцорам яица мешают )
а я соблюдая принципы, которые позволяют мне не ныть и не обвинять организации в том что они какие то плохие.
У меня более 100 проектов за плечами. Более 30 организаций. Если бы были плохие организации, я бы наверное их встретил )) Другое дело, что все проекты это всегда тяжело, всегда куча проблем, но если знать что и как делать, то все решаемо )
И в данной статье я постарался описать один из таких принципов. Не пускать программистов во внедрение.
В развитие - да можно и нужно.

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

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

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

32. novosys 13.02.12 15:06 Сейчас в теме

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

34. novosys 13.02.12 16:16 Сейчас в теме

Арчибальд, A.Y, Вы очень интересный подход описываете.
Итак, как продать внедрение 1С?
Мы НЕ спрашиваем у заказчика, что ему нужно... А зачем? Что бы там ни было - всё поместится в базовый функционал! А если что-то не влезет, так это НЕ ПРАВИЛЬНО! Перестроим заказчику все бизнес процессы "по-правильному", за что тоже возьмём денег, отдельной строкой. И зачем отдавать кусок программистам, что-то допиливая, если можно оставить его себе, убедив заказчика в том, что ему "истинно" необходимо, а что можно оставить на потом или вообще не автоматизировать. Приоритетность тех или иных потребностей также обозначим мы - у нас ведь опыт, заказчику прийдётся довериться нам.
Итого: мы внедрим заказчику то, что НАМ удобно за ЕГО, заказчика, деньги. Браво! Это верх мастерства консультантов. Классика, про кактусы и розы...

35. Арчибальд 2709 13.02.12 16:44 Сейчас в теме

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

39. 13.02.12 19:40 Сейчас в теме

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

(35) Арчибальд, залатые слова!

37. 13.02.12 19:30 Сейчас в теме

(34) ты все правильно понял :)
Истинный консультант делает не то что просит клиент, а то что ему нужно :)
Отличие плохого консультанта от хорошего состоит лишь в том, что хорошего по результатам благодарят, а плохого хаят :)
Причем вероятность, что тебя по итогам поблагодарят, выше если если будешь делать то что нужно, а не то что просят.
Если будешь делать то что просят, то вероятность быть обхаянным по результат на порядок выше.

Но принять такой принцип очень тяжело. Следование этому правилу подразумевает что вы готовы брать ответственность за решение на себя и отвечать за результат. А это дано не всем. Потому не у всех и получается )

40. novosys 14.02.12 11:10 Сейчас в теме

"Про кактусы и розы"

44. Новиков 292 21.02.12 09:26 Сейчас в теме

(40) novosys, это пять!

43. пользователь 15.02.12 13:21

Сообщение было скрыто модератором.

...

45. awk 744 22.02.12 00:26 Сейчас в теме

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

46. pro-rok 297 17.03.12 15:37 Сейчас в теме

Доброго времени суток господа. Я считаю что при доработке системы тем более УПП после внедрения может привести к тому что эта доработка не закончиться никогда и наложение одних программных заплаток потянет за собой необходимость в других. Тем более юзеры постоянно кричат с разных сторон хочу тут так, а там вот так, а каким образом это выльется на других пользователей никто не знает, пока не проверим, а проверять некогда потому что система внедрена и работает и доработки были нужны еще вчера. И баз проработанного ТЗ Вы господа окажитесь в попе.
Мой подход следующий что необходимо изначально проанализировать заказчика с его бизнес процессами и составить ТЗ причем не спеша, со всей необходимой проектной документации. А доработки нужны, что бы пользователю на первых этапах облегчить работу, а многие БП в УПП вообще могут не работать для конкретного заказчика, либо придется брать пачку бухов для вдалбливания цифр, а цена вопроса может быть в 5-10 т. рублей и пара тройка дней на выполнение и сдачу работы. Доработки без которых предприятие сможет прожить я всегда откидываю на потом.
Во всем должна быть системность, так что используйте системный подход дорогой для клиента и менее геморойный для исполнителя. Ну а если заказчик говорит мне это не нужно давайте приступай завтро. То я обычно предупреждаю что это кривая которая не известно где закончиться, и неизвестно сколько будет стоить и насколько качественной получиться работа . Если заказчика все устраивает тогда идем по короткой дороге.

47. ILM 241 04.04.12 19:27 Сейчас в теме

(46) pro-rok,
И вам всего Доброго. Заставьте пользователей и орунов-хотельщиков ответить на один вопрос: "Как это поможет организации зарабатывать деньги?".
Очень часто люди решают мелкие проблемы личного характера, которые никаким образом не влияют на доход организации.

48. mingaleevn@mail.ru 04.04.12 19:41 Сейчас в теме

Абсолют-сам проект. Старое ПО, ТЗ на бумаге и т.п. это только среда исполнения проекта.Вот этот этот этап, на котором вы сейчас скорее всего самый трудоемкий и долгий, в конце го вы получите "кусок сырого проекта", но его уже можно будет "положить в кастрюлю" =). Удачи!

49. diver.sun 21 17.09.13 11:18 Сейчас в теме

Первый вариант конечно хорошо, но есть нюанс. Составлять ТЗ кто будет, тот кто будет в дальнейшем автоматизировать, а по трудоемкости составление корректного ТЗ 50%-80% от стоимости проекта. А никто не обещает что после создания опуса мы по нему будем что то писать, вот и приходится порой бросаться в омут, надеясь выплыть и что то заработать, а не сидеть на берегу тщательно всё продумывая и проедая жирок(если он есть)

50. tango 546 17.09.13 11:30 Сейчас в теме

ниачём, да еще и перепечатка.
это хорошо, что не нашел, где нынче минусы ставятся, а то мышка потянулась уже
**
ага, нашел уже

52. bayce 48 05.01.14 20:29 Сейчас в теме

Полностью согласен с автором статьи.

53. Mishka_78 05.01.14 22:13 Сейчас в теме

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

Я бы еще несколько небольших дополнения включил (для объемных проектов внедрения):
1. Обучение пользователей на начальном этапе внедрения /и ее раз ОБУЧЕНИЕ/ - вообще в идеале сделать это требование обязательным на любом внедрении.
2. Обязательное наличие инф. ресурса, совмещающего в себе как минимум начальные функции HelpDesk (заявить о проблеме/получить инф. о ее решении) и базы АКУТАЛЬНЫХ инструкций пользователей и информации по проекту. Считаю обязательным ведение списка вносимых изменений и соответствующие информирование пользователей об изменениях.
3. Обязательные рассылки с актуальной информацией (можно привязать к п.2).
4. Обязательная мотивация персонала со стороны заказчика :). Рабочие группы по приказу по организации, персональная ответственность и конечно поощрения, поощрения и еще раз поощрения. :)
5. Все сроки по внедрению берем с запасом + 20 процентов.