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

[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. Система принимается в постоянную эксплуатацию. Осуществляем сервисное сопровождение.

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

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

[Aleck]

Цитата:

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

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

yandex - найдется всё!
ст.12 ФЗ-184
Вам стоит начать чтение со ст. 34 Конституции РФ, чтобы поверить что такое бывает =)))

Цитата:

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

ССЫЛКА

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

Я, конечно, очень извиняюсь, но не проясните как iso 9001 регламентирует "Стратегическое планирование продаж, производства и прочих видов деятельности, закупок, финансов (по стандарту ISO 9001)". А то у меня от прочтения такого сочетания мозг чуть не сломался. Представляю себе регламенты этих процессов по 9001 =))
Можно в общих чертах, без специфики клиента.

Кстати у вас 9001 реально работает или как в России 99% "внедрений" iso9001 исключительно для сертификата?

Цитата:

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

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

1. В России очень давно ГОСТ 34 необязателен, поэтому его мало кто и знает. Кстати, перечитайте свои ТЗ, проверьте насколько детально в них раскрыты подпункты 2.6.1. Отписки для соответствия ТЗ или серьезно анализируете, расписываете? Думаю при осмыслении разрыва ГОСТа и практики, а также того, что в РФ это только рекомендация, поймете почему он никому в РФ не сдался при внедрении ERP.
2. Большинство вменяемых автоматизаторов тем не менее на практике для проектов именно "создания" системы используют близкий к нему подход, но без перегибов ГОСТов 34/19 серии.
3. Внедрение ERP-систем, когда выбрана действительно подходящая система и адекватно определены рамки, кардинально отличается от "создания, развития или модернизации автоматизированной системы" тем, что (1) функционал не создается, а внедряется (2) при внедрении обычно меняются и многие процессы на предприятии, может происходить кардинальная реорганизация. В Белоруси, подозреваю, это редко случается из-за стабильности обстановки, а в России сплошь и рядом.

[Raven Melancholic]

Цитата:

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

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

Цитата:

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

yandex - найдется всё!
ст.12 ФЗ-184

Более конкретно про это говорит статья 46 п. 1