черновик статьи от 4 августа 2007
Гилёв Вячеслав aka Demiurg
присылайте предложения по
содержанию статьи на
gilev_slava@mail.ru

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

 Даже компания Microsoft вынуждена считаться с таким захватом рынка бизнес-приложений. Народная мудрость гласит, что лучше дружить, чем воевать. А на российском веб-сайте Microsoft появляются такие статьи как "Построение системы учета на основе платформы 1С: ПРЕДПРИЯТИЕ и программных продуктов MICROSOFT".

  В рамках этой статьи не хочется устраивать флуд о том, как скоро победит 1С SAP на его территории (автор намекает на офис, размещенный на родине SAP - Германии www.1cgermany.com ). Посмотрим на более приземленные проблемы, которые приходится решать и IT-руководителям, и внедренцам фирм - франчайзи 1С в рамках крупных многопользовательских систем.

Что хотел заказчик

Это картинка обошла наверно весь рунет. Действительно, уже к моменту выбора решения Заказчик должен представлять хотя бы Главную задачу, которую оно будет решать. В жизни все банальней.

Вот выдержка из Managing Software Requirements: A Unified Approach First Edition:

"Заказчики часто предлагают задания, которые можно условно представить как «Принесите мне камень». Когда камень доставлен, заказчик некоторое время изучает его и говорит: «Да, но на самом деле то, что я хотел, - это небольшой голубой камень». После доставки небольшого голубого камня выясняется, что это должен быть круглый небольшой голубой камень.
Наконец, может оказаться, что заказчик все время думал о небольшом голубом кусочке мрамора или он и сам в точности не уверен, чего же он хочет, но небольшого кусочка голубого мрамора - или даже кусочка голубого мрамора, имитирующего кошачий глаз - вполне достаточно. Кроме того, его мнение о требованиях могло меняться в промежутке между доставкой первого (большого) и третьего (небольшого голубого) камня.
При каждой последующей встрече с заказчиком разработчик, как правило, вопрошает: «Чего же Вы хотите?». Разработчик недоволен, поскольку он представлял себе нечто совершенно иное, долго и трудно работая над созданием камня с ранее описанными характеристиками; заказчик также расстроен, поскольку, даже если ему и сложно объяснить, чего же он хочет, он считает, что выразил это достаточно ясно. Эти разработчики просто ничего не понимают!"

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

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

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

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

Жена посылает мужа на рынок за улитками для косметического ухода за кожей. По дороге муж встречает друзей и на три дня уходит в запой, естественно, не приходя домой. Наконец на третий день вспоминает об улитках, идёт на рынок, покупает улиток и приходит домой. Думает, что бы сказать жене, почему его так долго не было... Звонит в дверь, жена открывает, он высыпает улиток на пол и, подгоняя их руками, говорит:
- Ну вот, пришли! Заходим, заходим, заходим...

Признак успешного проекта

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

Выбор решения, поставщика, исполнителя

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

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

Теперь, когда мы поняли, что заказчик знает в целом, Что надо сделать, а Исполнитель имеет опыт и знания как конкретно Это Сделать, рассмотрим некоторые те самые, Как Сделать.

Расчет параметров оборудования для информационной системы.

Это для небольшой фирмы все легко и просто с расчетом оборудования. Зашел на страницу рекомендаций и быстренько на коленке прикинул, сколько нужно "американских буказоидов" потратить. При количестве рабочих мест, стремящимся к 50 и выше, становиться весьма полезным раздел Примеры технологических параметров внедрений «1C:Предприятие 8. Управление производственным предприятием», где опубликована фактическая информация, которую можно использовать для сравнения.

Прикинем для примера, как посчитать, какой характеристикой должен обладать выделенный сервер СУБД с MS SQL Server 2005 для существующей информационной базы объемом 60 Gb.

Для "упрощенного" решения задачи воспользуйтесь запросом внутреннего языка 1С предприятие. Определяется количество документов, составляющих 80% документооборота (обычно это "Реализации товаров и услуг, ПКО и РКО, документы производства") и объем базы делите на полученное количество. Таким образом, зная сколько примерно килобайт пишет 1 документ, и количество документов за месяц, вы сможете оценить прирост базы за этот месяц. Допустим у нас получился прогнозируемый объем базы к концу года 90 Gb. Основной "чувствительной" характеристикой оборудования станет оперативная память, кэширующая таблицы регистров конфигурации. Старайтесь не устанавливать ОЗУ менее 30% от объема базы данных. Это значит что в нашем случае речь идет о 32 Gb. Вообще, памяти, как и денег, много не бывает. Поэтому, если вы спросите, будет ли лучше быстродействие при 64Gb, отвечу просто - будет. Особенно, если сервер СУБД обслуживает более одной базы данных.

Теперь о процессорах. Тут не простой ответ, так как для информационных баз 1С:Предприятия узким местом после ОЗУ обычно является жесткий диск, который может превратиться в место постоянной подкачки данных при неправильно подобранном железе и неоптимально написанном коде. И все же вспомнив про необходимость перестройки индексов и обновления статистики, автор статьи по опыту может смело сказать, что как минимум по ядру процессора на каждые 20 пользователей ставить придется.

А все ли учли в этом примере? А как заложиться на влияние кода информационной системы с учетом индивидуальных потребностей в каждом конкретном случае? Внедрение корпоративных информационных систем на платформе 1С:Предприятие 8 предъявляет более высокие требования к масштабируемости, функциональности и его качеству, а также квалификации обслуживающего персонала. В рамках разделов сайта 1С создан ресурс http://v8.1c.ru/expert, позволяющий более четко представить картину подготовительных действий. К тому же, и не всегда можно "рассчитать", какие параметры системы окажутся гарантированно работоспособными при минимуме затрат на оборудование. Теперь, вместо "шаманских бубнов" создан инструмент эмуляции работы пользователей, создающих нагрузку на будущую / существующую систему - 1С:ТестЦентр (и документация к нему).

Подробнее о подборе оборудования рассказано в статье Типичные ошибки при планировании серверных решений.

Проектирование системы для многопользовательского режима.

Существующие типовые решения, такие как 1С:Бухгалтерия Предприятия. Так, уже при 5-10 активно работающих пользователях в приложении происходят постоянные блокировки. И это понятно - в конфликт начинают вступать желания "видеть проводки" и "непротиворечивость данных при одновременном обращении/записи". Особенно остро проблемы возникают, когда систему дорабатывают начинающие специалисты, без опыта адаптации многопользовательских решений. Типичными ошибками можно назвать интерактивные действия при проведении, неупорядоченное обращение или избыточное обращение к данным при проведении документов, неоптимально с точки зрения быстродействия написанные запросы, отсутствие отборов, неиндексированные измерения/реквизиты, неоптимальный порядок измерений и т.д. Особенно остро встают проблемы взаимных блокировок, способных при отсутствии загруженности оборудования заблокировать любые действия, связанные с изменением данных в системе.

На рисунке хрестоматийный пример, когда Транзакция 1 (механизм обеспечения целостностной записи данных) зависит от транзакции 2 для ресурса блокировки таблицы Деталь. Аналогично Транзакция 2 зависит от Транзакции 1 для ресурса блокировки таблицы Поставщик. Так как эти зависимости из одного цикла, возникает взаимоблокировка транзакций 1 и 2. Это "безобразие" возникает в результате неупорядоченного обращения к "конкурентным" ресурсам таблиц Поставщик и Деталь.

Правильно будет Транзакции 2 начать попытку с блокировки таблицы поставщики, а затем продолжить попыткой блокировки Детали. В платформе 1С:Предприятие 8 для этих целей рекомендуется применять неявную запись движений платформой (т.е. автоматически), а регистры, к которым происходит обращение с целью дальнейшей записи, считывать с опцией "ДЛЯ ИЗМЕНЕНИЯ".

Для повышения качества внедрений в крупных организациях компания 1С практикует тренинги экспертов по технологическим вопросам.

Интересный эмпирический факт - более 25 человек, использующих Систему требуют выделенного специалиста. Небольшие количество (менее 15 человек) обычно обходится услугами сторонних фирм. Компании с "масштабом" более 100 специалистов, практикуют помимо своего IT отдела периодически привлекать сторонние фирмы.

Документация проекта

- это четкая постановка задачи! Если документация описывает нажатие кнопочек ради описания какие кнопочки можно нажать в этой программе - это макулатура.

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

Остальные моменты можно посмотреть в разделе Вопросы, сопутствующие установке клиент-серверного варианта 1С:Предприятие 8

Присылайте вопросы и пожелания на gilev_slava@mail.ru

Ошибки SQL описаны здесь.

Выбор серверного оборудования описан здесь.

Вернуться к списку статей