Фамилии исполнителей в договоре между клиентом и внедренцем

[dmitryul]

sukhanchik, Вы правильно отметили - цели и подходы разные.

Но не совсем верно. Точнее совершенно разный уровень вовлеченности заказчика в процесс внедрения.
И что, кстати, понимаем под слово "заказчик"? Только топ-менеджеры заказчика или?

От Lz_ так и не услышал слова "проектная команда со стороны заказчика" - это не только топ-менеджеры, это и ключевые сотрудники, и сотрудники ИТ-отдела компании, которые должны узнать новую систему заранее, перед тем, как обслуживать ее.

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

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

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

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

Но ИМХО, пользователи воспримут новую систему "в штыки" - их мнения не учли, на их уровне обследования не производилось. Не знаю, как считает Lz_, но большая вероятность того, что система не приживется.

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

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

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

[sukhanchik]

Цитата:

Сообщение от dmitryul

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

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

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

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

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

Цитата:

Сообщение от dmitryul

Но ИМХО, пользователи воспримут новую систему "в штыки" - их мнения не учли, на их уровне обследования не производилось. Не знаю, как считает Lz_, но большая вероятность того, что система не приживется.
...
Представляю сейчас - ставят Аксапту впервые, после 1С или Паруса или самописки, без детального обследования "на местах", со стандартной документацией и вперед в тестовую эксплутацию. Уровень саботажа со стороны сотрудников зашкалит. А потом еще говорят, что внедрение провальное.

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

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

[tvladimir]

Коллеги, забывают, что внедрение по определенной методологии, это не только требования к внедренцу, но и к Заказчику. Хватит ли знаний, сил и времени у сотрудников заказчика следовать 34 Госту? Я не уверен. Во многом поэтому и появляются "облегченные" внутренние методологии.

Например, Гост 34 однозначно говорит, что "Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием.". Замечательный тупик и колоссальная потеря времени. Вот и принимаются замечания типа "Я не уверен, что оборот по счету NN в корреспонденции с MM даст нужную мне расшифровку...".

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

Касаемо цели и задач проекта, то что они должны быть прописаны, это факт, хорошо так же прописать критерии достижимости. Но роль ПМ постоянно (можно сказать ежедневно) доносить (напоминать) ВСЕМ участникам проекта о цели и задачах. Как правило, через 1-2 месяца люди начинают их забывать, а после прочтения дизайна (тз и т.д.) в лучшем случае последует удивление...

[dmitryul]

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

Просто заострил внимание, что кроме ТЗ на внедерение (результаты анализа бизнес-процессов, как положено) по Sure Step мы пишем еще и подробный Дизайн системы (где подробно с картинками в Visio описываем как все это будет выглядеть o'naturel).

Ну и кучу других документов, как положено - ТЗ на разработку, ТЗ на тестирование, Рабочую документацию и пр.

Странно, Вы считаете, что по методологии Sure Step если у заказчика нет своих аналитиков (а обычно так и бывает, либо собственные аналитики не ахти какие) бизнес-процессы описываются хуже, чем по ГОСТ34?

Было время, пару лет назад я сравнивал ГОСТ34 и Sure Step и существенной разницы не заметил, ИМХО только отложилось, что без ущерба качеству, по Sure Step внедрить быстрее.

Надо бы еще раз перечитать ГОСТ, может что упустил?

Да, работа ПМ - это работа в первую очередь, c людьми.

[Lz_]

Цитата:

Сообщение от sukhanchik

2 Lz_ и dmitryul:
У вас обоих разные цели внедрения. Отсюда и разные методологии.

Я не согласен. Цель - одна. Это внедрить систему, кусок системы, функциональность, отчет и т.п, иными словами сделать то, что клиент хочет.

Судя по описаниям, которые вы привели, у меня сложилось такое впечатление, что ГОСТ 34 предназначен для создания систем (и это правда), а Sure Step лишь для выполнения доработок к уже существующей системе (что не совсем верно).

Sure Step является методологией внедрения является более четко "заточенной" для решения определенной задачи: внедрения продуктов MBS. К тому же эта методология снабжена полным комплектом шаблонов документов, что несомненно является большим плюсом.

ГОСТ 34 является государственным стандартом, определяющим требования к документации для создаваемой системы и стадиям ее создания. Тем самым ГОСТ является более широким и универсальным инструментом, который регламентирует создание любых автоматизированных систем: учетных, управления космическими кораблями или дверями в подъезде.

Но их нельзя противопоставлять, они лишь могут дополнять друг друга. Если, вдруг, у Sure Step и ГОСТ обнаружатся нестыковки или несоответствия, то руководствоваться следует ГОСТ, так как это государственный стандарт.

Есть ГОСТ 24.104-85 он определяет:

Цитата:

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

в то же время:

Цитата:

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

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

Цитата:

Сообщение от sukhanchik

Я тут наверное слишком категорично высказался. Суть в следующем….

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

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

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

Цитата:

Сообщение от tvladimir

Коллеги, забывают, что внедрение по определенной методологии, это не только требования к внедренцу, но и к Заказчику. Хватит ли знаний, сил и времени у сотрудников заказчика следовать 34 Госту? Я не уверен. Во многом поэтому и появляются "облегченные" внутренние методологии.

Каким образом «знания, силы и время у сотрудников заказчика» зависит от методологии? Вы по Sure Step полный комплект документации видели? Судя по шаблонам, количество документов в разы превышает требуемые ГОСТ .

Цитата:

Сообщение от tvladimir

Например, Гост 34 однозначно говорит, что "Замечания по проекту ТЗ на АС должны быть представлены с техническим обоснованием.". Замечательный тупик и колоссальная потеря времени. Вот и принимаются замечания типа "Я не уверен, что оборот по счету NN в корреспонденции с MM даст нужную мне расшифровку...".

Во-первых, ГОСТ не регламентирует процесс взаимодействия с клиентом и то, как будет проходить рецензирование проекта ТЗ. Формат взаимодействия и формат замечаний определяется методологией внедрения.

Во-вторых, приведенная вами цитата из ГОСТ 34.602-89 однозначно относится к приложению, которое носит рекомендательный характер, о чем и указано под словом «Приложение 1». Так что не нужно передергивать.

Цитата:

Сообщение от tvladimir

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

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

[Lz_]

2 dmitryul

Цитата:

Сообщение от dmitryul

Lz_, Вы внедряете по ГОСТ, лично я и многие другие мои коллеги - по Sure Step (впрочем, эти методологии похожи).

ГОСТ это не методология. ГОСТ - это система стандартизированных требований к документации и стадиям создания системы, являющихся государственным стандартом.

Цитата:

Сообщение от dmitryul

Мы продаем клиенту именно то, что он хочет увидеть - автоматизацию своих бизнес-процессов (новых, старых - не суть важно).

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

Цитата:

Сообщение от dmitryul

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

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

Цитата:

Сообщение от dmitryul

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

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

Сами придумали, сами ответили. Похвально. Продолжаем.

Цитата:

Сообщение от dmitryul

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

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

Цитата:

Сообщение от dmitryul

Да, мы продаем на обследовании часы. Разумеется, сроки обследования, затраченные часы на каждый из участок фиксируются и если фактически времени и ресурсов потрачено больше (обосновано) - клиент это оплачивает. Да, доработку он тоже оплачивает, если какие-либо бизнес-процесы поменял уже в процессе написания документа. ИМХО, я считаю обязательным со стороны клиента оплачивать все дополнительные часы при обследовании, если он отказывается - это проблемный клиент и стоит заложить дополнительные риски при внедрении (увеличить стоимость, увеличить сроки "на всякий случай").

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

Цитата:

Сообщение от dmitryul

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

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

Цитата:

Сообщение от dmitryul

Вы случайно не на стороне клиента работаете? Просто как-то странно читать такие посты, что обследование производится без предоплаты (либо с минимальной предоплатой), 60% предоплаты это много, клиент платит по акту подписания, дополнительные часы не оплачиваются.

Все предельно просто. У нас четкое соблюдение сроков и бюджета. Нет никаких дополнительных часов. Мы не продаем часы, мы продаем готовую систему или документ (ТЗ). Точно в срок и за те деньги, о которых договорились. Клиент действительно платит по акту подписания. Для изменения сроков и бюджета нужна очень веская причина. Это причина уж точно не «одни сотрудники говорили одно, начальство хотело третье, а руководство понимало все по-своему».

Цитата:

Сообщение от dmitryul

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

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

Цитата:

Сообщение от dmitryul

Госконтроль проверяет документацию на грамотное составления при внедрении АСУП на предприятии? Мда, даже не знаю что и думать - вот гайки в РБ закрутили, однако....

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

[dmitryul]

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

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

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

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

Грубо говоря Sure Step ближе к конечному пользователю, ГОСТ34 - ближе к гендиректору (собственнику предприятия). Соответственно, уровень детализации и акценты смещены в ту или иную сторону.

Обследование и внедрение по Sure Step - процесс "творческо-формализованный", по ГОСТ34 - жестко формализованный.

Цитата:

У нас четкое соблюдение сроков и бюджета.

назовите Вашу фирму, пожалуйста, и два-три клиента

[sukhanchik]

Цитата:

Сообщение от dmitryul

Просто заострил внимание, что кроме ТЗ на внедерение (результаты анализа бизнес-процессов, как положено) по Sure Step мы пишем еще и подробный Дизайн системы (где подробно с картинками в Visio описываем как все это будет выглядеть o'naturel).

Во! А зачем? Вот представьте себе - Вы хотите построить дом. Строители Вам дают подробную фотографию как все будет выглядеть в Visio o'naturel. Красиво? Безусловно. Нужно? Ну только на этапе сдачи. И все. После подписания акта приема-передачи - этот документ заказчику можно будет снести на помойку. Он ему не нужен будет в повседневной деятельности.

Цитата:

Сообщение от dmitryul

Ну и кучу других документов, как положено - ТЗ на разработку, ТЗ на тестирование, Рабочую документацию и пр.

Само собой - в полном соответствии с Sure Step.

Цитата:

Сообщение от dmitryul

Странно, Вы считаете, что по методологии Sure Step если у заказчика нет своих аналитиков (а обычно так и бывает, либо собственные аналитики не ахти какие) бизнес-процессы описываются хуже, чем по ГОСТ34?

Это... давайте не будем путать теплое с мягким. Ни Sure Step ни ГОСТ 34 не говорят - как надо описывать бизнес-процессы. Есть скажем так некие шаблоны, в которых отмечено - что должно быть отражено в документах - задании на разработку / тестирование. Задача же описания бизнес-процессов вообще говоря никак не связана с их автоматизацией. В описании бизнес-процесса присутствует много того, что вообще к системе не имеет отношения.

Цитата:

Сообщение от dmitryul

Было время, пару лет назад я сравнивал ГОСТ34 и Sure Step и существенной разницы не заметил, ИМХО только отложилось, что без ущерба качеству, по Sure Step внедрить быстрее.?

Еще раз сделаю акцент. Приходит клиент и говорит: Я хочу (к примеру) внедрить себе казначейство (новую функциональность).
Что говорит Sure Step ? "Скажите, а как вы это себе представляете?" Дальше клиент (один из сотрудников клиента) пытается изобразить желаемое. Дальше есть 2 варианта: а) у внедренца еще нет такого фунционала и он начинает вытягивать из клиента список форм и кнопок. Тут уж извините - чистый аутсорс пошел.
б) внедренец показывает уже имеющийся у него функционал, а клиент говорит что ему нужно переделать. Опять-таки подробно расписывая до кнопки. Дальше внедренец оценивает требуемый объем работ в часах, в деньгах и пошло поехало. Любое отклонение в сторону (а оно реально возможно - т.к. на этапе проектирования далеко не каждый человек способен продумать все вплоть до всплывающих подсказок) - стоит дополнительного времени внедренца (=денег клиента).

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

[Raven Melancholic]

Цитата:

Сообщение от Lz_

Если, вдруг, у Sure Step и ГОСТ обнаружатся нестыковки или несоответствия, то руководствоваться следует ГОСТ, так как это государственный стандарт.

Не совсем так. 184-ФЗ прямо говорит о том, что, за некоторым исключением, ГОСТы являются только рекомендательными документами и исполняются добровольно.
Понятно, что государственный заказчик, с большой вероятностью, потребует включения в договор пункта о соблюдении ГОСТ 34 (и/или 19).

[tvladimir]

2 Lz_

Цитата:

Каким образом «знания, силы и время у сотрудников заказчика» зависит от методологии? Вы по Sure Step полный комплект документации видели? Судя по шаблонам, количество документов в разы превышает требуемые ГОСТ

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

Вообще мне кажется, что выбор методологии, это некая степень недоверия к Заказчику. Если есть шанс с ними судиться, то документы нужно оформлять в соответствии с ГОСТ. Если вы доверяете заказчику, то можно обойтись связкой ФТ-Дизайн. Лично мне для внедрения (если заказчик идеальный) нужны только 2 документа - реестр модификаций и шаблон ввода начальных данных. Обо всем остальном мы договоримся, и через 2 недели люди начнут работать в системе (рекорд - 3 дня) в первом модуле. В противном случае, появится кипа документов.

Цитата:

Во-первых, ГОСТ не регламентирует процесс взаимодействия с клиентом и то, как будет проходить рецензирование проекта ТЗ. Формат взаимодействия и формат замечаний определяется методологией внедрения. Во-вторых, приведенная вами цитата из ГОСТ 34.602-89 однозначно относится к приложению, которое носит рекомендательный характер, о чем и указано под словом «Приложение 1». Так что не нужно передергивать.

Ну если у вас подписан контракт, где написано ГОСТ, то доказать, что вы используете или не используете рекомендации Заказчику очень сложно. Соответственно, считаем, что здесь я не прав.

Цитата:

Не все зависит от ПМ-а, например проект может быть не завершен в результате, например, смены владельца, смены руководства, мирового кризиса : ). В этом тоже виноват ПМ?

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

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

[ice]

Цитата:

Сообщение от sukhanchik

Только (что важно) - что клиент уже может работать в системе и нет никаких причин для того чтобы не работать - т.е. внедрение состоялось.

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

[sukhanchik]

Цитата:

Сообщение от ice

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

Да. Потому что ключевые (=существенные) требования были сформулированы и реализованы. А свобода есть только там, где она некритична.
Пример. Вопрос заказчика. Можно ли к документу в АХ прикрепить файл?
Ответ. Да, можно.
Такие моменты, как то, сколько для этого придется сделать кликов;
что более 5 Мб файл может не сохраниться в БД - это уже мелочи. Да, могло бы быть удобнее...наверное. Но оно ж работает. И не жужжит .
Пример конечно утрирован. Но в данном примере показано - что никто не расписывает - а вы сделайте мне флажок в гриде, который будет установлен у записей с аттачами, а можно ли тут сделать так, чтобы велся архив документов и т.д. Т.е. на выходе - имеем стандартную функциональность со всеми ее багами/фичами/прелестями. А экономию кол-ва кликов для МарьИванны - можно конечно сделать... Но потом.

[ice]

Цитата:

Сообщение от sukhanchik

Да. Потому что ключевые (=существенные) требования были сформулированы и реализованы. А свобода есть только там, где она некритична.
Пример. Вопрос заказчика. Можно ли к документу в АХ прикрепить файл?
Ответ. Да, можно.
Такие моменты, как то, сколько для этого придется сделать кликов;
что более 5 Мб файл может не сохраниться в БД - это уже мелочи. Да, могло бы быть удобнее...наверное. Но оно ж работает. И не жужжит .
Пример конечно утрирован. Но в данном примере показано - что никто не расписывает - а вы сделайте мне флажок в гриде, который будет установлен у записей с аттачами, а можно ли тут сделать так, чтобы велся архив документов и т.д. Т.е. на выходе - имеем стандартную функциональность со всеми ее багами/фичами/прелестями. А экономию кол-ва кликов для МарьИванны - можно конечно сделать... Но потом.

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

[sukhanchik]

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

[Lz_]

Цитата:

Сообщение от otkudao

назовите Вашу фирму, пожалуйста, и два-три клиента

Не смотря на то, что оформление документации в соответствии с государственными стандартами де-факто является стандартом фирмы, я не буду приводить ссылку на отзывы клиентов, внедрение АС у которых выполнялось не на AX. Приведу лишь те, к которым наш отдел имеет непосредственное отношение:
ССЫЛКА
ССЫЛКА
ССЫЛКА
ССЫЛКА

Сразу хотел бы предупредить, что ни при каких условиях, тем более на форуме, даже специализированном, я не буду:
1. Обсуждать клиентов с кем бы то ни было;
2. Обсуждать детали реальных проектов с кем бы то ни было;
Спасибо за понимание.

Краткое описание технологии разработки и внедрения

[Lz_]

Цитата:

Сообщение от sukhanchik

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

Внедренец при любой методологии должен быть "с головой". Очень сомневаюсь, что используя Sure Step «без головы» можно добиться положительного результата. Методология лишь облегчает внедрение и позволяет лишь снизить некоторые риски при внедрении.

Цитата:

Сообщение от Raven Melancholic

Не совсем так. 184-ФЗ прямо говорит о том, что, за некоторым исключением, ГОСТы являются только рекомендательными документами и исполняются добровольно.
Понятно, что государственный заказчик, с большой вероятностью, потребует включения в договор пункта о соблюдении ГОСТ 34 (и/или 19).

Не верю! Ссылку и цитату из 184-ФЗ можно?

Цитата:

Сообщение от tvladimir

Ну если у вас подписан контракт, где написано ГОСТ, то доказать, что вы используете или не используете рекомендации Заказчику очень сложно. Соответственно, считаем, что здесь я не прав.

Предметом договора является не процесс внедрения по ГОСТ или Sure Step, а готовая система. А вот в ТЗ указывается, что:

Цитата:

Выполнение работ по этапам календарного плана работ, оформление и предъявление Заказчику их результатов осуществляется по настоящему техническому заданию согласно требованиям группы стандартов П87 «Информационная технология. Комплекс стандартов на автоматизированные системы».

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

Цитата:

Сообщение от tvladimir

А как смена владельца влияет на завершение работ по проекту?

Реакция может быть абсолютно любой - от ускорения работ по проекту, до полной остановки проекта и замены систему на более «крутую» или понятную владельцу. И не всегда ПМ может повлиять на эту ситуацию.

Цитата:

Сообщение от tvladimir

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

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

[Lz_]

У меня складывается впечатление, что в результате обсуждения у некоторых коллег сформировалось ошибочное мнение что методология основанная на ГОСТ не позволяет учесть все пожелания и замечания пользователей, а методология на основе Sure Step только и предназначена для более тонкого тюнинга системы под потребности пользователя. Я в корне не согласен с таким утверждением. Документы, создаваемые по ГОСТ никак не регламентируют глубину проработки требований клиента. Глубина проработки целиком и полностью зависит от квалификации внедренца, степени «понятливости» клиента и готовности клиента принять документ в такой форме. Документ должен быть составлен так, что бы клиенту было понятно что будет на выходе.
По крайней мере, в нашей методологии масса мест, где пользователь имеет возможность подкорректировать систему.

1. Исходные требования – чаще всего клиенты самостоятельно формулируют на обычном бытовом языке чего они хотят добиться.

2. ТЗ – содержит:
Данные об объекте автоматизации;
Цели внедрения и критерии оценки достижения этих целей;
установлены четкие технические требования к системе в том числе надежность ;
определены функции системы;
определены входная и выходная информация системы;
определены функции пользователей, т.е. по сути, система «наложена» на организационную структуру предприятия и определены рамки ответственности;
определены состав и содержание работ по созданию системы, т.е. работы, которые выполняются в системе и ответственность за эти работы разделены между клиентом и разработчиком;
составлен календарный график проекта и работ по проекту;
определены требования по подготовке объекта автоматизации ко вводу системы: что должно быть готово для того, что бы начать реально внедрять систему;
требования к документированию: вот здесь четко и понятно расписано какие документы разрабатываются и на каких этапах передаются клиенту.
Создание ТЗ – это очень большой кусок работы. Начиная от упорядочивания требований и по сути архитектурных решений системы, до согласования с заказчиком всех требований функция, а главное функций пользователей (кто что делает и за что отвечает). И этот документ проходит рецензирование пользователями. В процессе рецензирования пользователи могут высказать (письменно ) любые замечания, которые будут рассмотрены. И решение учитывать или отклонить эти замечания принимает Клиент, а не разработчик. Это первая обратная связь.

К слову сказать, ТЗ - это основной документ по которому происходит приемка системы.

[ИМХО]
Если я не прав насчет Sure Step, поправьте меня.
В Sure Step, на сколько я понял, совокупность информации содержащейся в ТЗ по ГОСТ (не уверен в полноте, так как сильно глубоко не копал) появляется только после прохождения 2-х этапов: Диагностики и Анализа. При этом эта информация разрознена и находится в разных документах, которые интегратор может и не делать по разным причинам .
По методологии Sure Step техническое задание является выходным документом этапа Диагностика. Но на этом этапе нельзя сделать ТЗ, соответствеующее требованиям ГОСТ, т.к. для его создания не достаточно информации – этапа Анализ еще не было. И главная нестыковочка – это отсутствие единого документа в котором прописанный все критерии которым должна соответствовать система.
[/ИМХО]

3. Проектирование. Этот этап сильно зависит от сложности системы и объема внедрения. Если объем работ относительно не большой, то создается Технорабочий проект, если внедрение сложное и объемное, то Эскизный, Технический и Рабочий. Все они отличаются степенью детализации. Чем дальше, тем большая степень детализации. Люди реально изучают систему (стандартную + существующие доработки) и пытаются сделать так, что система выполняла свои функции и в то же время было удобно работать. Все эти проекты проходят этап рецензирования. Вот на этом этапе и определяется «весь тюнинг» системы. Это вторая обратная связь.

4. Разработка. Кодим, тестим, еще кодим, уточняем не понятные вопросы и т.п. Согласовываем программу и методику предварительных испытаний и тестовый пример. Импортим исходные данные и Клиент производит выверку данных. Все что криво залили переделываем . «Прогоняем» согласованный тестовый пример сначала мы, потом клиент. Огребаем кучу замечаний, клиент решает, что делаем, а что не делаем. Это третья обратная связь.

5. Опытная эксплуатация и приемка. Это работа в полях. Это, как правило, один из самых длительных этапов.
5.1.Сначала подготавливаем систему ко вводу в опытную эксплуатацию. Асапта уже установлена на рабочих местах, люди пытаются работать, крики, истерики, саботаж все проявляется на этом этапе. Мы работаем с пользователями, учим, объясняем, разруливаем сложные ситуации. Параллельно с ИТ клиента осуществляем техническую поддержку системы и пользователей, тем самым обучаются спецы клиента поддерживать систему решать возникающие проблемы и пользователи учатся работать в системе. Есть рабочий журнал, в котором пользователи пишут свои замечания и сообщения об ошибках и не доработках, ошибки устраняются, дополнительные бантики выносятся на заседание комиссии рецензирования. Примут – сделаем, не примут – не сделаем
5.2. Опытная эксплуатация. Это еще один из видов испытаний системы, всего из 3 (ГОСТ 34.603). По сути, полноценная реальная работа пользователей в системе в системе. Опять работаем с замечаниями. Пишут все начиная от замечаний по делу и просто «потому что так мне работать удобнее/лучше». На все замечания даем ответ. Ошибки – исправляем, если замечание является результатом ошибочных действия пользователя, то расписываем подробно что нужно сделать, что бы этого не было. Ответ пишется в журнале, если он объемный то отправлятся электронное письмо с инструкцией, а в журнале указывается дата и кому было отправлено письмо. Если замечание влечет за собой доработку, не оговоренную в документации, то замечание выносится на заседание комиссии рецензирования. Разрабатываем и принимаем Программу и методику приемочных испытаний. По результатам опытной эксплуатации большое заседание с полноценной обработкой замечаний. Если, система испытания выдержала, то принимается решение о проведении Приемочных испытаний. До начала приемочных испытаний все замечания пользователей подлежащие реализации должны быть сделаны. Это четвертая обратная связь.
Всё, система, по сути, полностью готова.
5.3. Приемочные испытания – третий тип испытаний. Тестируем быстродействие системы и надежность и достижение целей, короче, соответствие системы Техническому заданию. Считаем показатели надежности, если все ок – испытания завершены и система принята, если нет, то .

6. Система принимается в постоянную эксплуатацию. Осуществляем сервисное сопровождение.

Это кратенько по этапам. Для иллюстрации тезиса что система делается для клиента и у клиента есть масса возможностей подкорректировать систему. Я не упоминал обучение пользователей, документацию, которая передается пользователям и т.п.
Это упрощенный пример, когда проект идет линейно. В жизни какие-то части могут идти быстрее, какие-то нельзя начать до того как будут завершены предыдущие – это все планируется еще на этапе ТЗ. Вот почему ТЗ является таким важным документом проекта. Сдача каждого этапа подписывается клиентом. Если что-то клиента не устраивает, то он просто не подпишет этот этап.

А у вас внедрение как происходит?

работа по составлению ТЗ кем и как оплачивается?

[Lz_]

Цитата:

Сообщение от otkudao

работа по составлению ТЗ кем и как оплачивается?

Оплачивается заказчиком. Оплачивается деньгами, не едой же .

Форма, сроки и т.п. параметры оплаты оговариваются в договоре. Обычно договор заключается только на ТЗ. После ТЗ становится понятно во что это выльется по деньгам и срокам. Если у заказчика остается еще желание автоматизироваться, то заключается следующий договор предметом которого является система. И вперед.

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

UPD: Тема ветки - Фамилии исполнителей в договоре между клиентом и внедренцем. Предлагаю вернуться к этой теме.