Судя по частым вопросам типа: «Каким должно быть оборудование и сколько примерно будет стоить внедрение 1С при выполнении следующих условий. . .?», вызывает некоторое недоумение отсутствие необходимых нормативных сборников (типа СНиП – строительные нормы и правила) и специализированных проектно-сметных фирм которые бы давали четкий и обоснованный ответ на запрашиваемую информацию.

Реализация любого достаточно сложного и дорого производственного процесса теоретически должна осуществляться в три этапа:

1. Формирование полного набора требований к заявленной цели (решаемой задаче) и предпроектный анализ.
2. Выбор технического (технологического) решения и составление его проектно-сметной документации.
3. Внедрение проекта и получение его фактической себестоимости. Анализ расхождений.

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

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

Короче говоря, вопрос, кто мог бы здесь выступить заинтересованным лицом по созданию СНиПов для внедрения автоматизированных учетно-управленческих систем, в частности на базе 1С?

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

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

В идеале хорошо было бы иметь программу для расчета подобных смет, в зависимости от выбора основной технологии и ключевой техники. Например, это может быть классическая трехзвенная архитектура 1С8х либо терминальный сервер на базе толстых клиентов либо распределенная система со стандартным или от сторонних фирм механизмом обмена информацией либо какой-нибудь вообще нестандартный, но вполне работающий способ и т.п. Техника тоже может быть различной. Что лучше один супердорогой сервер или 20 дешевых серверов? Как последние тогда эффективно использовать. Нужно ли совмещать сервер 1С с сервером БД или нет? Проще говоря, как добиться нужных ТТХ от внедряемой системы самым эффективным и недорогим способом?

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

Собственно главный вопрос риторический – почему нет фирм, желающих занять нишу проектно-сметных работ для внедрения в общем случае нетиповых работ? Это направление нерентабельно или слишком трудоемко?

Bone serpentEmery,

Собственно главный вопрос риторический – почему нет фирм, желающих занять нишу проектно-сметных работ для внедрения в общем случае нетиповых работ? Это направление нерентабельно или слишком трудоемко?

Слишком трудоёмко. Фактически методов расчета трудозатрат и их стоимости не существует. Даже опытнейшие менеджеры проектов с мировыми именами прикидывают плюс/минус шапка с точностью плюс/минус хорошо если процентов пятьдесят.
Разве что оборудование вполне считается.
Трудоёмко для одного человека. Для фирмы это вполне подъемная задача. Насчет «не существует» очень даже не согласен. Возьмите любой СНиП и вы увидите, что там самые детальные расценки на любые работы.

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

Собственно говоря, можно даже ориентироваться на временные расценки работ. Например, прокладка одного метра сетевого кабеля, скажем, 10 минут. Установка и настройка, допустим, MS SQL Server – 40 часов, ввод первичных данных вручную 2 часа на килобайт, а при автоматическом переносе (написание программы) – 10 человеко-часов на 1 МБ данных. И т.д. и т.п. Цифры все условные. Затем просто тупо умножаем на стоимость рабочего времени тех специалистов, которые будут выполнять соответствующие работы.

Короче, надо писать что вроде 1С:Смета (тем более, что подобная конфигурация существует) + плюс чертежные работы + расчет оборудования и производительности для выбранной архитектуры.

vanechka_ivanEmeryВозьмите любой СНиП и вы увидите, что там самые детальные расценки на любые работы.

на какие на "любые"? копание канавы рабочим 4-го разряда? или что токарь делает однотипных деталей на станке за смену по норме 20 штук?

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

vanechka_ivanEmeryПроектировщики рисуют схемы и чертежи, а сметчики их обсчитывают.

у сметчиков зависимости как правило линейные... 1 землекоп - 1 куб грунта в час, 10 землекопов - 10 кубов

в IT зависимости нелинейные... два работающих правильно алгоритма будут давать разное время работы - в одном зависимость n^2 (10 элементов обрабатываются 100 секунд, 100 -> 10 000), а второй log (n) - (10 -> 1, 100 -> 2)

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

vanechka_ivanпо поводу оценки времени - сколько времени прошло (полвека)

а их по сути два:

1. по строкам кода - устарел и давно не применяется
2. по функ. точкам - крайне приблизителен

зы кста среди партнеров и прочих особо приближенных к селезневской вроде ходит какой-то инструмент с оценками спецов 1С на создание различных видов объектов метаданных
Можно использовать еще аккордную работу – плата по результату. Вы, скажем, беретесь перенести исходные данные (в свернутом виде) из устаревшей системы в новую (которая, если верить рекламе, всегда лучше старой). Называете свою цену, торгуетесь, если заказчик соображает, что к чему, выполняете свою работу и получаете соответствующую денюжку. Сколько там при этом будет у вас строк кода или «функциональных точек» заказчику до лампочки. Главное конечный результат.

Bone serpentEmery,

Внедрение учетно-управленческой системы не совсем «программизм».

Вот тут давайте поделим. Внедрение на части. И оценим каждую по возможностям формализированной оценки.

1. Составление ТЗ на разработку и разновсяческих требований.
2. "Программизм".
3. Закуп, настройка, введение в эксплуатацию железа
4. Изменение бизнес-процессов предприятия
5. Обучение пользователей.
Я бы предложил другую последовательность.

1. Выбор технологии и системы учета. Вот некоторые ключевые моменты для 1С: «семерка», «восьмерка», «терминал», «толстый клиент», «тонкий клиент», «веб-клиент», «файловая версия», «клиент-серверная» (как ее понимает фирма 1С), «распределенная система», «механизм обмена данными», «внешние компоненты», «нестандартные механизмы», параллельные базы данных, например, data warehouse, портал отчетов и т.д. и т.п.
2. Определение ключевых параметров – количество одновременно работающих пользователей, скорость доступа к данным (производительность), уровень надежности (избыточность) и др.
3. Расчет компонентов и оборудования (количество серверов, процессоров, ядер, памяти, дисков, параметров локальной сети и т.д. и т.п.).
4. Предпроектное обследование предприятия и сбор данных.
5. Выбор (адаптация) учетной политики предприятия к бизнес логике внедряемой системы.
6. Составление проектно-сметной документации.
7. Реализация проекта, в т.ч. обучение персонала.

Bone serpentЭто я скелетно, основные долгие и тяжёлые этапы. Кто-нибудь обязательно еще добавит.
На мой взгляд, нормально форматизуются с расчетом сроков и стоимости только 3 и 5.
Пункты 2 и 4 кардинально зависят от 1, при этом наличие/отсутствие административной воли у заказчика может дать погрешность в сотни процентов.
Фирма, создающая проектно-сметную документацию, должна быть способной реализовывать собственный проект в указанные ею срок и размер бюджета. Либо указывать, что ее документация является рамочной и ориентировочной, т.е. не вполне обязательной. Но и в этом случае можно указать допустимый диапазон расхождений. Например, если программист заявляет, что он напишет данную программу за время X, то в реальности это время будет N*X, где N – коэффициент от 3 до 6 (в среднем).

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

Bone serpentEmery,

7. Реализация проекта, в т.ч. обучение персонала.

<шутка>Понятно, откуда у вас мысли о внедрении IT-проектов по СНиПам. У вас бабушка не работала в СССР нормировщиком? :) </шутка>
Я сам работал во Всесоюзном НИИ, где проектировал и рассчитывал некоторые системы. И видел работу сметчиков. Кое-что даже программировал для них (позже в другом месте).

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

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

Bone serpentВы объединили большую часть внедрения, несущую основные риски, под одним невзрачным пунктом. Но риски-то никуда не делись.
Почитайте, например, «IT проекты Фронтовые очерки» Джо Мараска. Книжка лёгкая, читается хоть полностью, хоть главами. Но основное понимание о трудностях планирования и реализации IT-проектов даёт. Правда там больше про разработку, чем чистое (без "программизма") внедрение.
Риски идут от недостатка квалификации и информации, в т.ч. отсутствия полноценной проектно-сметной документации. Я внедрял некоторые проекты 1С, имею некоторое представление, хотя и не полное. Хотелось бы получить больший опыт.

kealon(Ruslan)Emery,

Пока вы не знаете что вам нужно и что вы хотите сделать - а вы не знаете
вам остаётся согласиться с тем, что оценить стоимость неизвестно чего - невозможно

да, есть нормы по
железу на пользователя

времени на курсы обучения персонала

но вот ни один из этих пунктов не гарантирует что это всё вместе будет работать (вплоть до "забыли включить розетку")

Розетку как раз забыть трудно. В СНиПах разделы типа «Электрооборудование», «Сетевое оборудование» и т.п. прописаны достаточно подробно, тем более есть уже автоматизированные сметные программы, вроде «Грант-Смета», вводишь параметры, получаешь готовую смету (при наличии соответствующих нормативов.

А то, что процесс внедрения 1С содержит много неформальных моментов, так это следствие нашего подхода – по наитию и «решение проблем по мере их возникновения». Этот подход можно и нужно менять. Только в рамках одного предприятия это как бы не очень выгодно, проект, как правило, разовый и делать работу с перспективой на множество подобных проектов не актуально.

Кстати, если почитать литературу на тему «модернизация предприятий», то увидим, что там решаются и более сложные задачи, чем внедрение 1С.

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

объявляете тендер на свои хотелки и смотрите цены, устраивает - покупаете, не устраивает (нет денег) - "сидите в Чишмах"
По всем пунктам здесь можно спорить. Экономика России имеет тенденцию к государственному планированию крупных проектов, пусть и посредством частных фирм (см. опубликованный доклад Сергея Глазьева на Совете Безопасности). Руководители страны, если надо, нагнут местные элиты, не говоря уже об «убедительных просьбах» к большому бизнесу. Так, вспомним поездку Николая Патрушева в Крым и Владимира Путина на космодром «Восточный» (где он говорил, в том числе, и об более двух тысячах уголовных дел в связи с проблемами строительства).

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

Тема обсуждения здесь может послужить основой для некоторого бизнес проекта. Кто уже этим займется и займется ли вообще это уже другой вопрос.

svcoderEmery, По своему опыту в 1С скажу, проектов на которых заказчик способен составить техническое задание до уровня реквизитов и алгоритмов - <10%.
Как по мне 10% даже много. Нормального техзадания не составит никто. Ибо это принципиально диалоговый процесс, заказчика с исполнителем, исполнителя с реальностью и т.п. Вот простой пример. Я написал обучающую программу на Adobe Air. Программа нормальная, делает все, что от нее требуется, легковесная. Но вот захотелось мне переписать ее на Qt по причине ограниченности возможностей предыдущей платформы. Техзадание (самому себе) самое, что ни на есть простое – сделать полный функциональный эквивалент по готовому образцу, но на другой платформе. Начал делать, но обнаружилось, что многие вещи можно реализовать лучше и более гибко. Следовательно, требования меняются на ходу, поскольку Qt как бы предлагает такие возможности, от которых просто невозможно отказаться.

Так что заказчик должен не ТЗ составлять, которое он по любому будет на ходу менять, а просто выдать перечень ключевых параметров. Например, внедрить учетную систему для производства (далее перечень конкретных хотелок). Мы осматриваем фирму, знакомимся с уровнем квалификации персонала и делаем свое предложение. Мол, для данного предприятия можно предложить 1С83:ERP-УП, 1С83:УПП, 1С83:MES-ОУП и даже 1С77:УПП (если не гнаться за понтами). Далее, в зависимости от одновременно работающих пользователей, требований к производительности и потенциального бюджета выбираем технологию: толстой клиент + терминальный сервер, тонкий клиент + кластер серверов 1С + доступный сервер БД, «секретный релиз» 1С77 + SQL Server 2012/2014, распределенную систему (это отдельный разговор) либо что-то основанное на нестандартных внешних компонентах. Причем здесь перечислены не все возможные случаи. Заказчик говорит, хорошо, но я сам не знаю, что я точно хочу. Мы, - нет вопросов вот вам набор типовых проектов и их смет, выбирайте. Т.е. грубую цену и сроки мы ему можем сказать сразу, более точная информация потребует дополнительной работы. Заказчик, - вы знаете, денег у меня не очень много, понты меня не интересуют, вот мне понравилось ценовое предложение по семерке, только как там насчет легальности «секретного релиза»? Мы, - это под вашу ответственность, но можем предложить легальный способ работы монопольного клиента «семерки» через нашу внешнюю ОДБС компоненту с любым сервером БД, по который есть соответствующий драйвер, например, MySQL. Только стоить это будет чуточку дороже. Клиент, - согласен. И мы ваяем ему проектно-техническую документацию и даже можем сами осуществить ее реализацию под заявленную стоимость системы + стоимость процесса внедрения, либо заказчик будет внедрять собственными силами, а мы только контролировать данный процесс.

Т.е. я вижу процесс работы с заказчиком где-то так.

svcoderКроме того, у программного проекта 1С есть особенности по сравнению с остальными проектами, как программными так и остальными):
1. Изменение требований. Если же требования зафиксировать - вполне может получиться проект, который никому не нужен.
Для этого составляются заранее укрупненные проекты и сметы. Скажем, вот на аналогичном предприятии подобный проект стоил столько-то миллионов рублей. У вас будет, в связи с тем-то и тем-то, примерно на такое количество процентов больше или меньше. Если вас устраивает сама концепция, то подробности будут в конкретной проектно-сметной документации. Причем можно предложить даже несколько вариантов, в зависимости от концепции, если заказчик готов оплачивать эти работы.

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

svcoder3. Огромная (на порядок) разница в производительности доступных ресурсов для выполнения проекта.
Если недостаточно ресурсов (согласно укрупненной смете), то надо выбирать другой проект, по средствам. Допустим, проект гарантирует нормальную работу для 20 пользователей, но тормозит на 25. У заказчика сегодня 15 пользователей, но завтра может быть 30. Мы ему честно говорим, что следующий адекватный проект на 20-50 пользователей будет стоить раза в три-четыре дороже. Делать модернизацию с одного типа проекта на другой будет более трудоемко и дорого, так что может быть лучше раскошелиться заранее либо нести дополнительные издержки на собственный страх и риск. Опять таки, цифры здесь условные.

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

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

svcoderА вообще, достаточно сравнить количество различных способов обработки детали и количество различных способов реализации среднего алгоритма, чтобы понять, что в программных проектах ошибиться в оценке гораздо проще.
Да вы возьмите, например, задачи Капицы для одаренных школьников, когда при неопределенных условиях требуется посчитать результат и оценить его погрешность. Ошибка в расчетах не проблема, если она не выходит за допустимую погрешность. Просто есть такой принцип, что более точные расчеты требуют больше времени и цена их растет экспоненциально. Таким образом, с точностью, скажем, до 100% мы вам стоимость проекта скажем быстро, а с точностью до 10%, через пару месяцев, причем эта работа будет стоить столько-то. Вы согласны?

Bone serpentEmery,

Так что заказчик должен не ТЗ составлять, которое он по любому будет на ходу менять, а просто выдать перечень ключевых параметров
Заказчику нужно еще объяснить, что считать ключевыми параметрами. Он этого обычно не знает. У него задача простая, например, "автоматизируйте мне склад". Сам же диапазон автоматизации получается от "два документа и три отчета" до сложнейших WMS.
Можно задать ему косвенные вопросы: «Какой объем товарооборота и документооборота на складе?», «Сколько сотрудников занято при этом?», «Их квалификационные обязанности?» и т.п. Да и просто посмотреть все своими глазами.

Смысл простой вы задаете заказчику вопросы, на понятном ему языке и делаете выводы. Потом предлагаемее ему проект решения, один либо несколько. Если же заказчик «дуб, как дерево хвойное», то можно ограничиться одним вопросом: «На какой бюджет он согласен?». Из этого и пляшете. Только дурить тупого заказчика не нужно, себе дороже. Всегда найдется какой-нибудь умник, который скажет ему, что тебя, мол, развели как лоха. Доказывай ему потом, что ты не верблюд.