IT консалтинг - статьи

Автоматизация без дураков

, журнал "IT Manager" #14(2)/2004
Автоматизация бизнес-процессов – термин, который на слуху уже не первый год. Обещая баснословную прибыль, многочисленные «автоматизаторы» внедряют под знаменем новейших технологий разнообразные решения, призванные повысить эффективность бизнеса своего клиента. И часто это происходит так, что клиент слабо ориентируется, как же происходит процесс внедрения, а фирмы, осуществляющие внедрение, не утруждают себя, чтобы сделать автоматизацию хоть сколько-нибудь прозрачной. Данный материал поможет устранить некоторые пробелы в понимании того, что же скрывается за словами «процесс внедрения АСУ».
Итак, вы решили внедрить на своем предприятии систему автоматизации бизнес-процессов. Прежде чем искать исполнителя, нужно уяснить некоторые принципиальные моменты. Главный из них – внедрение должно быть действительно необходимо, то есть иметь экономическое обоснование. При этом речь может идти об автоматизации бизнес-процессов, тогда его цель — повышение надежности и оперативности предоставления информации и выделение большего времени сотрудников на ее анализ, а не на обработку. Кроме того, цель автоматизации может состоять в реорганизации бизнес-процессов. В любом случае стоимость внедрения достигает 1-2% от месячного оборота компании (разумеется, речь идет о комплексной автоматизации). Если же бизнес-цели не ясны или бюджет вашего предприятия просто не выдержит рыночной цены внедрения, то лучший выход — отложить подобное мероприятие.
Следует понимать, что внедрение не сводится к покупке коробки. Любое программное обеспечение требует поддержки, и деловое – в особенности. Обновления, связанные с изменениями законодательства, корректировка отдельных моментов учета или кардинальная перестройка процессов, вызванная ростом или реорганизацией предприятия, – все это должно входить в услугу поддержки и сопровождения внедряемого решения.
Важный момент состоит в том, что самостоятельное внедрение так же эффективно, как и самолечение. Простых областей учета и управления нет. На изучение и кодирование потребуются месяцы и годы работы. Так что уж лучше сразу решить, что эффективнее - доверить внедрение опытному «врачу», или путем собственных проб и ошибок добиваться призрачных целей. Кроме того, вам нужны не контрагенты, а союзники. Организация, осуществляющая внедрение, должна быть не только безукоризненна в профессиональном отношении, вы, прежде всего, должны доверять ей. Речь идет не только о той информации о вашей компании, которая станет доступной данной организации в процессе внедрения. Во внедрение обязательно будут вовлечены руководство и предметные специалисты, обязательно появятся разного рода проблемы, поэтому вам необходима уверенность, что вас не обманут.

Фаза анализа

Для начала попытаемся разобраться, зачем вообще нужна фаза анализа. Здесь все достаточно просто: нам необходимо понять, достигнута ли цель, и выявить факторы, способствующие или препятствующие этому. Анализ нужен, чтобы определить сильные/слабые стороны бизнеса. Причем следует помнить как о субъективных, так и об объективных факторах.
Любой бизнес имеет бюджетную и операциональную составляющие. Бюджетный план и план мероприятий нельзя однозначно выразить друг через друга, но система управления должна учитывать это. В обязательном порядке анализу подлежат как бюджетная, так и операциональная составляющая бизнеса. Ошибка на данном этапе приводит к неправильным (недостижимым) целям на следующем витке цикла. В лучшем случае — потеря денег, в худшем — потеря клиента.
Для того чтобы все вышесказанное обобщить, рассмотрим два конкретных примера.
1. Компания Y занималась крупной оптово-розничной торговлей товарами определенной группы. Перед топ-менеджерами была поставлена задача увеличения прибыли. Топ-менеджеры решили выяснить, какие товарные позиции приносят большую прибыль. Через месяц они это выяснили и решили убрать плохо продающиеся товары. Затем они выбрали несколько самых ходовых позиций и увеличили по ним закупки, а от остальных отказались. В результате компания осталась без ассортиментных позиций. При отсутствии ассортиментного минимума резко снизились продажи и самых ходовых товаров — их стали покупать у конкурентов.
2. Компания Z занималась крупной оптово-розничной торговлей товарами, импортируемыми из-за границы. Так же, как и в предыдущем примере, перед топ-менеджерами была поставлена задача увеличения прибыли. Рынок к этому моменту уже устоялся, и топ-менеджеры решили, что единственная возможность качественного улучшения ситуации находится не на уровне бюджетных решений (увеличение числа и пропускной способности каналов поставок, конкурентное снижение отпускных цен и т. д.). Следующим их шагом был анализ выполнения всей логистической цепочки доставки товара:

Определение и согласование параметров заказываемого товара с продающими филиалами.

Заказ товара у поставщика.

Отправка заказанного товара поставщиком.

Прибытие товара на таможню.

Доставка до центрального склада.

Контроль качества и определение условий хранения.

Доставка до филиала или местного склада.

Продажа.

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

Было решено ввести еще один этап (между этапами 2 и 3). Этим новым звеном стал этап Согласования. Появились две новые должности:
1) менеджер, отвечающий за согласование отклонений с поставщиком. Он несет ответственность за то, что поступит именно согласованный товар;
2) менеджер, отвечающий за то, что согласованный товар будет востребован и продан филиалом.

Этого оказалось достаточно для существенного сокращения потерь.

Фаза контроля

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

Фаза планирования

Процесс составления планов есть коллективный процесс работы менеджеров, в течение которого планы обсуждаются, корректируются, утверждаются. Рассмотрим этот процесс на примере планирования постоянных расходов.
1. Финансовый директор делает в системе пометку о начале планирования.
2. Автоматически всем пользователям системы рассылается сообщение о начале планирования следующего периода, его сроках и deadline предоставления плана.
3. IT-менеджер, в числе прочих ответственных, получает указанное сообщение и начинает планировать, допустим, следующий месяц.
4. Он указывает номер декады (недели, точную дату — все зависит от выбранной модели), статью расхода и сумму. Причем заранее составлена проекция менеджеров, участвующих в планировании, на статьи затрат. Это значит, что IT-менеджер никак не сможет планировать налоги или зарплату основного производственного персонала, поскольку ему это запрещено. Но выбрать статью — оргтехника и провести по ней $600 (поддержание и текущий ремонт) он сможет.
5. Завершив планирование, менеджер оценивает свои планы, что-то меняет и ставит отметку.
6. Автоматически система формирует сообщение, что тогда-то такой-то IT-менеджер предоставил все планы.
7. Финансовый директор, таким образом, получает консолидированную информацию от всех отделов.
8. Затем, как правило, полученные планы не удовлетворяют финансового директора (а может, генерального директора или акционеров). Финансовый директор или дает задания подразделениям что-то изменить, или в пределах дозволенного меняет сам. Но с автоматическим предупреждением всех заинтересованных лиц.
9. В результате в системе формируются приемлемые для всех сторон (естественно, с учетом их веса) бюджеты расходов и платежей.
10. Финансовый директор закрывает указанный период для планирования, после чего всем автоматически рассылаются оповещения об утверждении (невозможности дальнейшего изменения) бюджетов.
В результате сформированы четкие планы расходов и выплат предприятия на предстоящий период. На практике процедура разработки и утверждения подобных планов занимает от 3 до 10 дней в зависимости от сложности бизнеса и скорости принятия решений. Учитывая требования конкретного менеджмента, указанная процедура может быть проще или сложнее. Например, возможно лимитирование определенных статей (в абсолютных величинах или в процентах от других статей) — на рекламу нельзя тратить более 6% всех поступлений от продаж и т. д.

Фаза выполнения

Прежде всего, нужно понять, что фаза выполнения ни в коем случае не ограничивается только лишь учетом – бухгалтерским или управленческим. Эта фаза включает в себя так же управление персоналом, маркетинг и т.п.
Если продолжить пример с описывающий фазу планирования, то автоматизированный процесс фазы выполнения выглядел бы примерно так:
1. Подчиненный IT-менеджера (или он сам) вводит в систему заявку на выплату, допустим, $630, указать статью — поддержание оргтехники, и способ оплаты — безналичный. По плану же на данную статью полагалось $600.
2. Менеджер видит перерасход — $30 (в общем случае — величину неизрасходованного остатка по статье) и отсылает такую заявку финансовому директору.
3. Финансовый директор получает сообщение о новой заявке от IT-менеджера, видит перерасход по ней и текущий остаток денежных средств на том счете, с которого она будет уплачена.
4. Если финансовый директор согласен, он утверждает заявку и продолжает ее движение по маршруту. Если не согласен — отклоняет, что означает возврат заявки к ее отправителю с указанием причины отвода.
5. В случае утверждения заявка попадает к бухгалтеру, который, после получения необходимых документов (счета, акта, счета-фактуры и т.д.), ставит свою визу — «проведено».
6. Дальше бухгалтер по банку одним движением на основании заявки печатает платежное поручение. Заявка получает статус — «удовлетворена».
Надо отметить то, что необходимым элементом документооборота является доступность ответственным лицам информации о том, кто и как долго обрабатывал заявку, и в какой стадии она в данный момент находится. Естественно, на практике было много нюансов. Например, если заявка удовлетворяла плану, то этап 3 мог и отсутствовать.

Экипировка

С тем, как строить маршрут, разобрались. Но важен не только маршрут, но и экипировка. Итак, есть сложная, но результативная последовательность этапов. Каждый этап должен быть задокументирован и утвержден заказчиком. Первый документ этапа - план его выполнения. Второй - план-факт исполнения работ. Третий - собственно результат этапа: «Отчет о постановке задачи», «Схемы автоматизируемых бизнес-процессов», «Техническое задание», «Должностные инструкции».
У фирмы-внедренца должны быть стандарты на эти документы, причем в таком виде, чтобы потенциальные клиенты всегда могли с ними ознакомиться. Нет единого стандарта? Внедренец готов работать по любой предложенной заказчиком форме? Значит, это плохой внедренец. Нельзя плясать под дудку заказчика, ведь он не профессионал. Только представьте - приходите вы к врачу, а он вас спрашивает: «Как будем лечиться?». То есть нужен еще один документ. В начале каждого этапа заказчик должен утвердить формат документа результата по данному этапу. Хорошо, если этот формат будет совпадать/коррелировать с общепринятыми — ГОСТ, IDEF. Цель - предсказуемость результата.
Таким образом, только ознакомившись с форматами документов, сопровождающих работу внедряющей компании, не потратив ни единого у. е., вы сможете оценить потенциальных внедренцев именно по качеству работ, а не по субъективному восприятию. Опасно опираться на мнение знакомого главного бухгалтера, мол, их автоматизировала фирма, и результат очень хороший. Часто результатом для главного бухгалтера будет увеличение его авторитета, влияния, количества подчиненных, что вряд ли совпадает с оценкой результата внедрения для фирмы в целом. И наоборот, если вам говорят, будто кто-то недоволен результатом внедрения, это может означать обратное. Например, вряд ли результатом проекта по автоматизации крупной фирмы останется доволен уволенный (ставший лишним) восемнадцатый бухгалтер или менеджер по продажам, не добившийся успеха.

Коэффициент автоматизации

Автоматизация нужна для повышения эффективности бизнеса. Каким образом?
Допустим, существует сотрудник, должностные обязанности которого достаточно формализованы (регламентированы). Если они не сложны и нагрузка не велика, то нет проблем. Но что происходит на практике при увеличении нагрузки, причем нагрузка здесь — не обязательно в увеличении операций, это может быть повышение цены принимаемых решений, нервная нагрузка и прочие факторы. А происходит следующее: количество выполняемых за единицу времени производственных операций уменьшается, зато вероятность технологических ошибок увеличивается. Поэтому замена алгоритмизируемых человеческих операций на машинные совершенно формально приводит к увеличению эффективности и надежности всей системы. Именно в этом и состоит задача автоматизации. Из этого же следует критерий оценки автоматизированной системы:
Коэффициент автоматизации (AQ) обратно пропорционален количеству алгоритмизируемых, но не автоматизированных операций.
То есть чем больше осталось ручной, рутинной работы, тем он ниже. Плохо автоматизированная система в предельном случае является просто хранилищем информации, в которое кто угодно или что угодно просто вводит данные, потом эти данные, как правило, массой выбрасываются пользователю, который волен поступать с ними, как хочет.
Поэтому существует опасность недоавтоматизации. Предположим, на некотором предприятии в системе была реализована поддержка планов, учета, планирования и контроля. Вроде бы хорошо. В числе прочих составлялся бюджет выплат. Но на самом деле учет выполнения планов велся без предварительного контроля, т. е. при плане выплат в 100 единиц сотрудник мог сделать платеж на 500, и на следующий день менеджер видел результаты контроля — отклонение — 400. Правда, было уже поздно, так как отменить действие невозможно. Поэтому перед любым платежом сотруднику приходилось сопоставлять план выплат, произведенные выплаты и намеченную выплату, а хранились они в разных подсистемах и т. д. и т. п. В итоге – затрачено лишнее время, появляется раздражение и ошибки. А достаточно было просто проработать механизм лимитирования, и при попытке превышения лимита оператор получал бы соответствующее уведомление и рекомендацию отправить заявку на согласование и утверждение. То есть система с необходимой степенью гибкости реагировала бы, и больше того — регламентировала бы деятельность оператора.
Но существует и другая опасность - опасность переавтоматизации. Предприятие купило престижную информационную систему (западного производства), вложив в нее сотни тысяч долларов. Номенклатура товаров — около 10 000, поставок — до 500 в день. И вместо обычных кладовщиков предприятие вынуждено взять на работу квалифицированных программистов для ввода накладных и подготовки отчетности. А все потому, что в этой КИС товар представлялся двенадцатизначным кодом, и пользователю каждый раз требовалось набирать в документах эти цифры, специальным образом ежедневно расшифровывать из данных штрих кодового оборудования, копировать и импортировать файлы, и снова преобразовывать коды в отчетах. И любая ошибка или несвоевременное выполнение операций приводили к серьезным проблемам. То есть оперативность и достоверность информации, которую предоставляла информационная система, зависела от такого числа человеческих факторов, что сбои фактически были запланированы.
Получается интересный вывод, указывающий на близость IQ (коэффициент интеллекта) и AQ. Знаменитый закон Тейлора гласит: «Из двух кандидатов, одинаково пригодных для работы, следует выбрать более глупого». То же и с компьютерными информационными системами — из двух систем, одинаково пригодных для автоматизации вашего предприятия, следует выбрать ту, у которой AQ ниже (более глупую). По крайней мере, будет экономия денег.

Маршрут правильного движения

Единственный, но зато гарантированный способ сохранить здоровье при движении по незнакомой, сильно пересеченной местности — это, как известно любому альпинисту, точный маршрут и соответствующая экипировка. Процесс внедрения не менее запутан и сложен, чем маршрут по горам, и имеет те же свойства. Подобно любому маршруту, внедрение должно быть ограничено как в пространстве — иметь конечную цель, так и во времени. Нечеткость в этих вопросах приводит к тому, что блуждания становятся бесконечными, а цель — недостижимой. Сложный маршрут (а простых внедрений не бывает) всегда состоит из этапов. В случае автоматизации эти этапы можно выделить следующим образом.
Этап 1. Стратегическое планирование. Топ-менеджеры компании должны сформулировать бизнес-цели и стратегию на ближайшие год-два. Это задачи именно высшего руководства. Как правило, цели впервые ясно формулируются как раз в результате этого этапа.
Этап 2. Формализация бизнес-процессов. После понимания задач можно переходить к следующему этапу — постановке задач на автоматизацию. Кратко - какие задачи будут автоматизированы и как. В ходе данного этапа составляются схемы движения информации (по одной на функциональную область — планирование продаж, закупка, хранение и т. д). На этом этапе в работе принимают участие топ-менеджеры, ведущие специалисты, начальники подразделений подготовки и IT-менеджеры. В результате данного этапа цели руководства будут сформулированы на языке конкретных функций и задач всех подразделений компании. Таким образом, это фактически этап постановки задачи.
Этап 3. Оптимизация бизнес-процессов. Первое системное и реальное представление о целях и бизнес-процессах, подлежащих автоматизации, полученное в результате второго этапа, почти всегда неоптимальное. Поэтому для повышения эффективности они должны быть оптимизированы. Обычно в результате оптимизации происходит реорганизация либо структуры предприятия, либо бизнес-процессов — реструктуризация и реинжиниринг соответственно.
Этап 4. Техническое задание. Опираясь на утвержденную постановку, можно разрабатывать ТЗ. Иными словами, постановка задачи отвечает на вопрос: «Что надо автоматизировать?», а ТЗ — «Как конкретно надо автоматизировать?». ТЗ составляется с IT-менеджерами и начальниками отделов — «собственниками бизнес-процессов». В задании детально описываются все объекты информационной системы, их поведение и т. д. И чем подробнее будет ТЗ, тем лучше. На этом этапе очень важен процесс документирования, чтобы потом не возникали проблемы расхождения взглядов компании-клиента и внедряющей стороны.
Этап 5. Кодирование. После утверждения ТЗ можно приступать к кодированию. Это дело внедряющей организации.
Этап 6. Разработка должностных инструкций. Создание должностных инструкций – этап, часто игнорируемый заказчиками, которые требуют переходить сразу к обучению персонала. Но именно должностные инструкции облегчат в дальнейшем и обучение, и опытную эксплуатацию – меньше придется волноваться и заказчикам, и внедренцам. Опыт показывает, что этапы кодирования и разработки должностных инструкций могут проходить параллельно.
Этап 7. Обучение пользователей. В результате внедрения практически всегда происходит реинжиниринг и реструктуризация. Это означает, что сотрудники предприятия будут вынуждены работать по-новому. И проблема состоит не только в том, что их нужно известить о грядущих изменениях и научить работать в новых условиях. Основное, пожалуй, в том, чтобы преодолеть психологическое сопротивление переменам, позитивно настроить коллектив. Другими словами, нужно учесть и человеческий фактор.
Этап 8. Опытная эксплуатация. Этап, на котором можно объективно оценить все сделанное ранее. Система начинает работать не на бумаге и показывать свою эффективность/неэффективность.

На сегодняшний день, как во

На сегодняшний день, как во всем мире, так и в России существуют разнообразные решения на различных платформах, призванные в максимально короткие сроки автоматизировать деятельность предприятий. Это различные MRP, ERP, а также довольно распространенные в странах СНГ системы на базе «1С:Предприятие». Но в любом случае, абсолютно готовых к употреблению решений не бывает - каждое предприятие имеет свои особенности, которые нельзя первоначально учесть в универсальном пакете. Более того, при внедрении западных систем надо быть всегда готовым к тому, что они не очень-то рассчитаны на специфику деятельности на российских просторах, и это может увеличить время внедрения.
Но, тем не менее, эффективность автоматизации бизнес-процессов давно доказана, и единственным препятствием на пути внедрения является непонимание его сути заказчиками и непрофессионализм исполнителей. Хотя уже сегодня в России ощущается значительный прогресс в данном направлении, что не может не внушать оптимизм.
document.write('');

Сроки

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

Стоимость

Сколько стоит внедрение? Автоматизация - это бизнес. Значит, определение стоимости процесса описывается общими экономическими законами. Труд среднего специалиста средней внедряющей фирмы объективно определяется временем его работы. Поэтому у каждой внедряющей фирмы единица трудозатрат определяется квалификацией персонала — эта единица является базой для расчета. А как на практике устанавливается стоимость внедрения? Известно три способа договорного определения стоимости внедрения.
Способ 1. Авантюрный. Внедрение всегда производится с целью оптимизации бизнеса, и результатом внедрения будет увеличение прибыли автоматизируемого предприятия либо за счет расширения бизнеса, либо за счет сокращения потерь, либо за счет и того и другого. Вот на некоторую долю прироста прибыли, полученного в результате автоматизации, стороны и договариваются. Этот способ достаточно редок. Солидная внедряющая фирма на это никогда не пойдет по следующей причине - нести прямые затраты ей придется сейчас (время, потраченное на внедрение специалистами компании), а окупятся они в будущем или нет, будет зависеть от персонала заказчика. То ест, проконтролировать этот процесс нельзя. Риск огромен.
Способ 2. Проектный. Способ, любимый руководством автоматизируемых предприятий за кажущуюся простоту и ясность. Способ действительно ясный, но вот последствий этой ясности заказчик себе, как правило, не представляет. И это может привести к серьезным проблемам. В таком случае стороны четко оговаривают, что, в какие сроки и за какие деньги будет сделано. Серьезная внедряющая фирма формализует это в договорных документах следующим способом: Постановка задачи определяет, что именно должно быть сделано; ТЗ определяет, как должно быть сделано то и только то, что определено в Постановке; Кодирование — кодируется то и только то, что определено в ТЗ. Такая система позволяет внедряющей фирме точно определить себестоимость и стоимость проекта, а также планировать ресурсы. Но что произойдет, если после подписания договора и постановки задачи заказчик вдруг обнаружит, что по какой-либо причине стоящие задачи изменились и часть заявленных в постановке задач в том виде, в каком они утверждены внедренцем, ему уже не нужна? Внедряющая фирма на основании подписанных простых и ясных документов имеет полное право сделать ненужную работу и добиться оплаты ее договорной цены. Кроме того, коль скоро сроки работ определены, внедряющей фирме не выгодно их растягивать — норма прибыли уменьшается, и она обязательно будет использовать подписанные документы с оговоренными сроками для того, чтобы не дать заказчику затянуть сроки (увеличить скорость принятия решения заказчиком). Иными словами, при проектном способе реальную ответственность берут на себя обе стороны, но одна из сторон редко отдает себе в этом отчет.
Способ 3. Рамочный договор о сотрудничестве. Жизненность этого способа определяется его гибкостью. В отличие от проектного способа стороны констатируют общее видение предполагаемых задач, сроков и стоимости, но фиксируют лишь те задачи и этапы работ, которые им ясны на 100% (принимая на себя двустороннюю ответственность), и договариваются, что новые задачи можно формулировать и выполнять оговоренным способом, по мере их прояснения. И так до тех пор, пока окончательная цель не будет достигнута. Меньшая жесткость - меньший риск. Возможность внесения оперативных корректировок гарантирует меньший расход ресурсов (они не тратятся на выполнение ненужной работы), а значит, гарантирует лучшее, по сравнению с проектным способом, соотношение результат/цена.

Управление

Процесс управления практически любым объектом можно представить циклом (рисунок). Если, скажем, мы управляем кораблем, то Целеполагание — это принятие решения доплыть, например, из Ливерпульской гавани в Бразилию; Планирование — это решение о том, что для пополнения запаса горючего нам необходимо зайти в промежуточный порт, например, на Кубу; Исполнение — это собственно плавание; Контроль — это необходимость прочитать название порта и убедиться, что попали именно на Кубу, а не в Каир; Анализ — соотнесение желаемого местонахождения с действительным; Формирование управленческого воздействия — оргвыводы и приказ заменить проштрафившегося штурмана; Корректировка — изменение планов или целей в зависимости от величины промаха, ну и так далее. Более того – каждая фаза в отдельности должна быть тоже управляема, а значит, и иметь свои целеполагание, планирование, исполнение, контроль и анализ.
Автоматизированная система управления в общем случае должна автоматизировать именно этот цикл, так как именно он является определением термина «управление». Вопрос в том, какие фазы управленческого цикла подлежат автоматизации? Достаточно очевидно, что не целеполагание и корректировка, которые пока являются прерогативой человека, поскольку на этих этапах разрабатывается/корректируется миссия, стратегия предприятия, его глобальные планы (имеющие в основном качественную оценку) или производится изменение плана — процесс, тоже не подлежащий алгоритмизации. На всех же остальных стадиях автоматизация весьма и весьма уместна. В любом случае сбои на любой стадии управления приводят к тому, что объект становится плохо или вовсе неуправляемым.
Итак, при автоматизации системы управления предприятием автоматизировать нужно фазы планирования, исполнения, контроля и анализа. Все четыре. А если к вам приходит фирма-автоматизатор и утверждает, что после проведенной ею автоматизации, скажем, бухучета, наступит полный порядок, то вряд ли им можно доверять. Бухучет принадлежит фазе контроля. Допустим, вы знаете месячный объем продаж. Но его не с чем сравнивать, следовательно, непонятно, как регулировать этот объем. А если бы у предприятия существовал план по объему продаж, то каждый день менеджер получал бы информацию: укладывается он в план или нет, и в результате чего возникло отклонение. Согласны, что в этом случае менеджер действительно владеет информацией и является именно менеджером, а не бухгалтером или секретарем?
Разберем фазы, подлежащие автоматизации, подробнее.

IT консалтинг - статьи

Анализ требований рынка.

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

Что есть PLM

Главная цель любого производителя — качество выпускаемой продукции, однако одной из основных тенденций сегодня является необходимость сокращения времени выхода новых изделий на рынок при одновременном удовлетворении специфических потребностей заказчиков (от модели массового производства компании переходят к разработке и сборке на заказ). При этом компании не могут позволить себе повышать стоимость процессов проектирования новых изделий. Одновременно с этим в процесс создания продукции вовлекаются сегодня многочисленные внешние участники — от поставщиков комплектующих, которые должны иметь возможность оперативно реагировать на изменения в требованиях к конечному продукту, до самих заказчиков, которые хотят получить доступ к процессам формирования этих требований. Для многих крупных производителей «виртуальное предприятие» становится реальностью — они выносят за скобки собственного производственного процесса разработку и выпуск комплектующих, а подчас и собственно сборку готового изделия, оставляя за собой базовые операции выработки концепции и проектирования продукции. Передача части своих функций на аутсорсинг не отменяет необходимости контролировать и интегрировать все процессы. Для того чтобы виртуализация производства происходила не в ущерб конечному результату и с максимальной экономической отдачей, компаниям необходимы технологии, объединяющие и автоматизирующие все разрозненные этапы жизненного цикла изделия, создающие интегрированную среду коллективной работы, где каждый участник производственной цепочки имеет в реальном времени доступ к нужной ему информации по изделию.
Первоначально такие технологии приобрели известность под названием Collaborative Product Commerce (СРС), однако термин PLM (Product Lifecycle Management) точнее отражает суть. PLM — это набор взаимосвязанных прикладных решений, включающий необходимые программные компоненты обеспечения коммуникаций, интеграции модулей, автоматизированного проектирования и визуализации и других решений, охватывающих полный жизненный цикл продукта — от идеи до утилизации. PLM расширяет возможности автоматизированного контроля над изделием за рамки инженерных лабораторий и конструкторских бюро, которые были основными пользователями предшественников РLM-технологий — CAD/CAM и систем PDM. Решения класса PLM призваны объединить всех участников жизненного цикла, как внутри предприятия-производителя, так и вне его, в том числе поставщиков, заказчиков и организации, занятые послепродажным обслуживанием продукции.
Система PLM охватывает все этапы жизненного цикла изделия (рис. 1).

Рис. 1. Этапы жизненного цикла изделия

Что влияет на темпы распространения PLM-решений

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

Дистрибуция.

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

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

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

Формирование репозитория PLM как

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

Литература

Aberdeen Group, Worldwide PLM Spending (from the engineering perspective). Forecast and analysis 2001-2005. 2002 December.

В. Климов, В. Краюшкин, М. Пирогова, Настоящее и будущее PDM. // Открытые системы, 2002, № 2.

M.Burkett, ERP will never meet all the PLM requirements of innovative manufacturers. AMR Research, 2003 February.

По данным Aberdeen Group [1] объем рынка PLM-решений к 2005 году составит 5,12 млрд. долл. и его ожидает ежегодный рост, несмотря на стагнацию мировой экономики. К традиционным пользователям — крупным производственным корпорациям — начинают присоединяться средние компании, и наряду с США активно осваивать PLM-решения продолжат Европа и Азия.
***
Выстроить в одной системе всю цепочку процессов жизненного цикла, обеспечить их взаимосвязь и разделение информации на разных стадиях работы над продуктом позволяет централизованный репозиторий, в котором система PLM сохраняет данные, полученные на каждом этапе.
***
По данным Aberdeen, в мире более 50% затрат на PLM-решения приходится на оплату услуг консультантов. Aналитики также прогнозируют повышение интереса к рынку PLM ведущих производителей аппаратного обеспечения, которые могут использовать возможность поставки специально сконфигурированных серверных платформ вместе с приложениями PLM как шанс придать новый импульс продажам своей техники.

Необходимость преодолевать общекультурные сложности.

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

Определение источников поставок (PLM-sourcing).

Отдел закупок должен провести предварительную работу по поиску источников приобретения необходимых для производства изделия деталей, материалов, компонентов, оборудования и т.д. Задача систем PLM — предоставить достоверные данные о доступности тех или иных деталей/компонентов/материалов, их стоимости, потенциальных поставщиках и возможных альтернативных источниках.

По данным аналитиков, рынок PLM-решений

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

Послепродажное обслуживание.

На этом этапе выполняются техническое сопровождение, обслуживание и ремонт — в течение гарантийного срока или как дополнительно оплачиваемый сервис. PLM позволяет учесть различную информацию об изделии, поступающую на этом этапе жизненного цикла, при разработке последующих проектов и тем самым способствует повышению привлекательности продукции для клиентов.
Возможность извлечь из одного источника не только все накопленные на данном проекте знания, но и исторические данные, имеет ключевое значение для повышения эффективности проектирования новой продукции и усовершенствования существующей номенклатуры изделий с целью максимального удовлетворения потребностей заказчиков. Репозиторий PLM позволяет производителю не растерять ценный опыт, накопленный на предыдущих проектах. Возможность не изобретать в очередной раз велосипед крайне важна для производственных предприятий, поскольку, как показывает практика, большинство проектов не несут в себе какой-то исключительной новизны, а являются усовершенствованиями предыдущих разработок.
При наличии централизованного репозитория значительно упрощается контроль за актуальностью информации — PLM становится для компании единственным источником достоверных данных по продукту. Чем раньше будут идентифицированы ошибки или ограничения проекта, которые могут повлиять на конечные характеристики разрабатываемого изделия или просто усложнить процесс его производства, тем меньше затрат понадобится на их устранение. Перепроектирование, а тем более, дополнительное тестирование, переделка или, того хуже, полная отбраковка готовой продукции всегда обходятся изготовителю недешево. Pешения категории PLM позволяют свести к минимуму или полностью избежать подобных расходов, а если учесть, что, по оценкам Aberdeen, не менее 70% затрат на производство и сопровождение продукции приходится на этап проектирования, можно сделать вывод, что PLM обеспечивают не только повышение качества и оптимизацию разработки изделия, но и способствуют снижению затрат на поддержку его жизненного цикла. По данным IBM в сотрудничестве с компанией Dassault Systemes, предлагающей свой РLM-пакет ENOVIA, с применением возможностей PLM экономия затрат на разработку и выпуск продукции у ее клиентов достигает 1 млрд. долл., при этом цикл вывода нового изделия на рынок сокращается с 72 до 16 недель.

В PLM доступ к данным организован на ролевой основе. Система позволяет предоставлять пользователю информацию в форме, соответствующей выполняемым им функциям в жизненном цикле изделия: трехмерные модели, схематические диаграммы, инженерные спецификации (bill of materials, BOM), календарные планы или прогнозы на основе анализа требований рынка. Конструктор будет работать в привычной ему среде САПР, а сотрудник маркетингового подразделения сможет получить из системы представление трехмерной сборки, пригодное для размещения в рекламной брошюре.

Системы CAD/САМ, нашедшие широкое применение в производственных компаниях, повышали эффективность и упрощали работу проектировщиков и технологов, но были слабо интегрированы между собой, а другие подразделения и партнеры компании практически не могли повлиять на процессы разработки и производства изделия, поскольку не имели доступа к таким системам. После последовательного проведения нескольких итераций разработки проект попадал к технологам и в отдел закупок, которые уже никак не могли повлиять на него и подчас были вынуждены идти на неоправданно дорогие траты или поиск дефицитных материалов и деталей и производство изделия на неподходящем оборудовании. Система PLM, объединяющая все структурные подразделения предприятия, позволяет уже на этапе проектирования вносить изменения с учетом проблем, которые могут возникнуть как при производстве, так и при выборе поставщиков комплектующих. В результате не возникнет ситуации, когда невозможность увязать проект со сложностями производственного цикла и задачами закупок приводит к повышению цены и одновременно снижению качества продукции.

С помощью информации, которую интегрирует система PLM, даже не обладая специальными техническими знаниями, сотрудники отдела закупок смогут заниматься поиском нужных деталей и выбором оптимальных каналов поставки непосредственно по данным, поступающим из конструкторских подразделений. По мере развития технологии электронного представления компонентов (component supplier management, CMS) и появления у поставщиков возможностей параметрического поиска, которые будут интегрироваться в PLM, сами конструкторы уже на этапе проектирования получат возможность выбирать подходящие компоненты. По данным Aberdeen, привлечение поставщиков на этапах формирования концепции и проектирования изделия обеспечивает 20% экономии средств на разработку. Кроме того, они все чаще выступают в роли проектировщиков определенных компонентов изделия. Бумажные формы обмена информацией с внешними котрагентами компании-производителя существенно снижают эффективность работы над изделием, поскольку время обнаружения ошибок в проекте влияет на его стоимость и на сроки вывода качественного продукта на рынок. Предположим, производитель автомобилей отдает на аутсорсинг разработку переднего амортизатора. В ходе проектирования корпуса может измениться спецификация для амортизатора — длина, вес или степень упругости. Эти изменения сразу должны быть учтены в проекте, который разрабатывает смежник, что и позволяет сделать среда PLM через механизмы разделения данных для разных участников жизненного цикла изделия.


Если идея интеграции поставщиков комплектующих в процессы проектирования на самых ранних стадиях для ряда производителей, например, в автомобильной отрасли, уже давно перешла в практику, то возможность включения в информационное пространство изделия подразделения и внешние организации, которые занимаются послепродажным обслуживанием, можно считать «ноу-хау» PLM-решений. Знания о том, какие проблемы вызывает техническое сопровождение готовой продукции, ее гарантийное или платное обслуживание, может серьезно повлиять на последующие проекты компании. Если производитель имеет возможность получить такие данные, проанализировать их и реализовать в следующих проектах те характеристики, которые позволят избежать аналогичных проблем для нового изделия, он не только сэкономит свои затраты на послепродажное обслуживание, а сделает продукт, который лучше удовлетворит запросы клиента. А это уже влияеет на имидж и конкурентоспособность производителя.

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

В целом, преимущества, которые дает PLM-решение, можно сформулировать следующим образом:

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

совершенствование характеристик разрабатываемой продукции и повышение качества, обнаружение недостатков и ограничений проекта на самых ранних стадиях;

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

учет и использование опыта других проектов;

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

Потребители

Рис. 2. Распределение прибыли от PLM-решений по функциональности систем

Решения РLM выросли на почве создания расширений к существующим САПР для построения сред совместной работы проектировщиков, поэтому сегодня наибольший процент использования возможностей PLM принадлежит инженерной сфере (рис. 2). Около 75% рынка PLM в 2002 году приходилось на предприятия автомобильной промышленности, ИТ-индустрию, самолетостроение и машиностроение. Эти дискретные производства имеют опыт не одного десятилетия по использованию САПР и PDM-систем, и потому вполне логичен их интерес к новому поколению решений по управлению данными об изделии. Кроме того, эти четыре отрасли в мире представляют уже вполне зрелые рынки, на которых необходимо искать особые пути выделить себя среди конкурентов. Они уже миновали стадию ценовых войн, и теперь на первый план выходят такие параметры, как качество выпускаемой продукции, качество и высокий темп инноваций, эффективность поддержки полного жизненного цикла продукта. Но вслед за ними преимущества PLM-решений начинают по достоинству оценивать и другие отрасли, где необходимо серьезное внимание к стадии проектирования и поддержка достаточно длительного жизненного цикла производимой продукции: производство потребительских товаров и бытовой электроники, строительство, фармацевтика. При этом более 80% рынка PLM остается за дискретными производствами.
Первыми пользователями решений PLM были крупные компании (более 5 тыс. сотрудников) — одной из основных причин является накопленный опыт работы в среде САПР/PDM, ну и, конечно, материальные возможности. Именно их вложения позволяют рынку PLM-решений развиваться в сторону создания готовых пакетов PLM-приложений и постепенного снижения цен, что открывает перспективы использования PLM для средних (от 500 до 5 тыс. сотрудников) и небольших (от 20 до 500 сотрудников) компаний. За повышением интереса к PLM со стороны предприятий этого уровня лежат определенные тенденции в современном производственном бизнесе. Как правило, большинство таких предприятий являются поставщиками для крупных производителей, и потому нуждаются в механизмах увязки своих процессов проектирования и производства компонентов с теми целями, которые ставит «старший» партнер. Более того, основной производитель все чаще передает на аутсорсинг те или иные операции по разработке и сборке компонентов или даже сборке целого изделия. Такая бизнес-модель «виртуального» предприятия требует эффективной автоматизированной среды совместной работы, которую и обеспечивают системы PLM. Однако эта новая категория клиентов более сдержана в своих расходах и более подвержена влиянию экономической нестабильности, поэтому, чтобы иметь успех в этом сегменте рынка, поставщикам потребуется приложить больше усилий по формированию предложений, в которых будет найдено оптимальное для средних предприятий сочетание цены, функциональности, возможностей быстрой инсталляции и простоты в использовании.

Проблема руководства.

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

Проектирование.

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

Производители

В центре объединения различных этапов жизненного цикла, которое реализует система PLM, пока остается ключевой для производства процесс проектирования, поэтому легко объясним тот факт, что первопроходцами современного рынка РLM стали производители САПР и систем PDM: РТС, EDS/SDRC, IBM/Dassault Systems [2]. Аналитики AMR Research выделяют эти компании в группу так называемых САПР-центричных поставщиков решений класса PLM [3]. Другая категория поставщиков в классификации AМR — это производители ERP-систем, такие как SAP, Oracle, Baan. Осознав стратегическое значение для своих заказчиков интеграции всех процессов по выпуску продукции на базе мощной информационной системы, эти компании стали активно предлагать собственные PLM-решения.
Технологические корни систем представителей этих двух групп определяют и основные различия между ними. «САПР-центричные» компании сильны в обеспечении наиболее неформальной, творческой части жизненного цикла изделия — многоитерационного проектирования в среде совместной работы над неструктурированными данными различной степени сложности. На базе этого ядра строятся взаимосвязи остальных этапов жизненного цикла с центральным процессом проектирования, позволяющие понять, какое влияние оказывает проект на производство, определение требований к поставщикам, анализ предпочтений клиента, послепродажное обслуживание, и вывести обратные зависимости. Производства, где быстрые и эффективные модификации и создание новых изделий имеют критическое значение, такие как автомобильная промышленность и авиастроение, составляют основную клиентскую базу поставщиков PLM-решений из этой группы.
Традиционная сфера применения ERP-систем — бизнес-транзакции над структурированными данными, планирование ресурсов, контроль финансовых потоков, управление поставками, обеспечение информации для поддержки управленческих решений, контроль за выполнением плана. Свои PLM-решения компании «ERP-центричной» группы в основном строят вокруг структурированной спецификации изделия (ВОМ), на основе которой интегрируются процессы управления проектами, контроля за конфигурацией изделия, документооборота, управления потоком работ, управления цепочками поставок и взаимоотношениями с клиентами. Получающие сейчас распространение в ряде производственных компаний процессы разработки на заказ (engineer-to-order, ETO) и конфигурирования на заказ (configure-to-order, CTO), которые требуют управления структурой и конфигурацией изделия на протяжении всего жизненного цикла — оптимальная сфера применения таких PLM-систем.

AMR выделяет еще одну группу игроков на рынке РLМ — независимые компании, не имеющие серьезного «веса» ни в сфере САПР, ни в области автоматизации общего управления корпоративными ресурсами — это Agile Software, MatrixOne, Eigner. Их решения имеют развитую функциональность для различных стадий жизненного цикла изделия за рамками трехмерного проектирования, включая поддержку взаимосвязей с внешними партнерами, и интерфейсы для интеграции в среду PLM необходимых САПР и ERP-приложений.

Задачи интеграции разных систем вообще актуальны для современного рынка PLM. На больших проектах может понадобиться комбинация возможностей, как это произошло, например, при реализации программы по созданию аэробуса А380 в компании Airbus, где решения SAP используются совместно с функциональностью систем РТС и IBM/Dassault. У производителя и поставщика могут уже быть установлены модули, на базе которых возможно построение общей PLM-среды. Другой вариант — производитель хочет дополнить имеющиеся у него модули автоматизированного проектирования и управления данными об изделии функциями управления взаимоотношениями с поставщиками и заказчиками, обратясь к решениям другого поставщика. Кроме того, на западном рынке есть целый ряд небольших компаний, производящих продукты, реализующие отдельные функции для управления жизненным циклом изделия, такие как моделирование материалов, 3-D анимация, управление технологическими процессами, поддержка среды совместной работы проектировщиков, тестирование готового изделия, автоматизация закупок, управление инженерными проектами, поддержка технического обслуживания и т.д. Они привлекательны для многих клиентов, поскольку приобретение полномасштабной платформы PLM требует первоначальных затрат в несколько миллионов евро, поэтому компании часто предпочитают «кусочную» автоматизацию, постепенно объединяя модули, приобретенные для решения частных задач. Одна из важных проблем формирующейся индустрии PLM — это стандартизация, возможно, создание в стеке программного обеспечения PLM общего уровня взаимодействия, позволяющего клиентам интегрировать на некую единую платформу оптимальные для себя решения по поддержке разных стадий жизненного цикла продукта.

Сложность PLM-решений как таковых, а также необходимость их интеграции в корпоративную информационную среду клиента, которая может включать самые разные системы — от собственных разработок и унаследованных приложений до последних новинок в области SCM и CRM, объясняет динамику развития профессионального сервиса на рынке РLM.

Производство.

В соответствии с определенными на этапе проектирования спецификациями и с использованием полученных на этапе поставок деталей и материалов производится продукт. Реализованные в PLM специальные методы контроля качества позволяют гарантировать соответствие производимого изделия заданным спецификациям.

Стандартизация.

В области PLM стандартизация необходима как в сфере представления данных частными САПР и PDM-системами, так и для создания общего синтаксиса для совместного использования данных модулями разных РLM и другими корпоративными системами. Эволюция и адаптация стандартов в этой области, как и в любой другой, требует времени.
Общекорпоративный масштаб PLM-решений (в идеале) ставит и серьезные проблемы их внедрения. Поставщики и консультанты по PLM сегодня стремятся избежать неприятностей, которые почти обязательно сопровождают развертывание решений аналогичной сложности, например, ERP: затягивание сроков проекта, постоянный рост расходов на реализацию и неудовлетворенность заказчика темпами возврата инвестиций. Поэтапная реализация PLM-проектов помогает ускорить окупаемость и получать реальный эффект от внедрения уже через полгода с начала реализации.
Но, несмотря на все трудности, современные производственные компании понимают, что необходимое условие для стабилизации и развития бизнеса — совершенствование всех процессов, связанных с созданием продукции. Чтобы стать известным или удержать репутацию своей марки, надо обеспечивать высокое качество проектирования и производства. А сложные экономические условия подчас только подстегивают: клиенты в это время становятся более разборчивыми.

Поставщики PLM-решений

Выработка концепции проекта.

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

IT консалтинг - статьи

Управление компанией можно довести до автоматизма

Сергей Кабанов, Профессор БГТУ "Военмех" им. Д. Ф. Устинова,

IT Manager #5(11)/2003
Большинство специалистов, как в нашей стране, так и за рубежом полагают, что Россия слишком медленно продвигается по пути рыночного реформирования экономики. Соответственно, медленно меняется и вся система общественных отношений в государстве, затягивается переходный период, что не способствует поддержанию социальной устойчивости. Одна из основных причин такого положения - несовершенство и неэффективность менеджмента. Такое положение особенно опасно, поскольку при неразвитых институтах гражданского общества адекватность управленческих решений, прежде всего, на верхнем уровне, всегда имела большое влияние на все стороны жизни. Сказанное справедливо и для оценки значения выверенности и своевременности управленческих воздействий для устойчивости системы на отраслевом уровне или в рамках конкретного предприятия.
Для обеспечения экономического равновесия в стране, даже при наличии цивилизованных рыночных отношений, также требуется квалифицированный менеджмент, поскольку без вмешательства со стороны государства нельзя поддерживать отраслевую и региональную сбалансированность экономики.
Причины торможения реформ понятны. Очевидна также потребность в скорейшем привлечении в управленческую сферу людей, способных адекватно оценивать обстановку и оперативно принимать выверенные решения. При этом следует иметь в виду, что при общей неразвитости методологии, учитывающей специфику России, эффективный менеджмент затруднителен даже в рамках крупных корпораций, имеющих возможность привлекать высококвалифицированных топ-менеджеров и специалистов. Неэффективными оказываются и собственные аналитические отделы. В еще более трудном положении находятся небольшие предприятия, для которых подобные возможности не доступны. Как максимум, они могут набрать персонал из числа выпускников профильных высших учебных заведений, не имеющих опыта практической работы.
Хотя на Западе и нет острого дефицита управленцев, а рыночные отношения и вся сопутствующая инфраструктура органично встроены в социальную систему, аналогичные проблемы существуют и в западных странах. Правда, там, наоборот, имеет место все большее расширение управленческого аппарата, развитие аналитических служб, занимающихся изучением рынков, управлением рисками, совершенствованием системы стимулирования работников, рекрутингом и т. д.
В связи с этим в рамках развития современных технологий управления производством разрабатываются и внедряются системы, обеспечивающие оперативный бухгалтерский и управленческий учет, логистику и поставляющие информацию, которая может служить основой для оценки деятельности и выработки мотивированных управленческих решений. В настоящее время для серьезной западной корпорации оснащенность подобной системой стала стандартом и необходимым условием успешного ведения бизнеса.
Однако так называемые управленческие технологии позволяют только систематизировать и обрабатывать информацию, осмысление которой и принятие конкретного решения предоставляется менеджерам. Но анализ всей поступающей информации, пусть и соответствующим образом обработанной, может оказаться весьма сложной задачей, а принятые решения - неоптимальными. Это утверждение особенно актуально, когда решения приходится принимать в условиях регионального или глобального экономического кризиса.
В то же время в актуальных для нас условиях неустановившегося рынка особое значение приобретает именно выверенность решений текущего управления, его оперативная корректировка по результатам реальной оценки состояния предприятия и его положения на рынке. Менеджер, управляющий коммерческой фирмой или банком в условиях экономического кризиса, может быть уподоблен пилоту боевого самолета. Как на борту самолета неверный приказ или неправильная последовательность возможных действий ставят под угрозу жизнь экипажа и выполнение боевой задачи, так и в кабинете руководителя предприятия - принятие ошибочного решения приводит к потере рынка, краху бизнеса и т. д.
Следует отметить, что в характерных для России условиях нестабильности и динамичности наиболее востребован именно тип управления в режиме on-line. Это вполне согласуется с принципом Р. Эшби, в соответствии с которым сложность и быстрота решения (управления) должна соответствовать сложности и быстроте изменений рыночных условий.
В настоящее время на рынке компьютерного ПО (программного обеспечения) не существует систем, предлагающих менеджменту предприятия подготовленный набор решений по текущему управлению. Препятствие к их созданию в отсутствии адекватных математических моделей социально-экономических объектов, учитывающих человеческий фактор. Трудность заключается в том, что кроме бухгалтерской отчетности и некоторых очевидных показателей производственной деятельности на предприятиях нет естественных, количественно отслеживаемых внутренних технологий. Кроме того, именно человеческий фактор чрезвычайно усложняет изучение изменчивых связей и закономерностей, присущих предприятию, внося элемент неопределенности, затрудняющий прогнозирование. В результате сложилось стереотипное представление о нереальности эффективной идентификации, то есть разработки адекватной математической модели подобного объекта и оптимального управления им.
Между тем подход к решению задач, связанных с управлением объектами, изменяющимися во времени и не имеющими математических моделей, уже найден. Один из путей к решению был открыт после разработки академиком РАН А. А. Красовским в 1994 году принципа безмодельного управления объектом на основе регулятора нового класса (с самоорганизацией), обладающего высоким быстродействием и устойчивостью к шумам измерения, иначе - сигналам случайного характера, отражающим субъективные, несущественные для управляемого процесса изменения как вне, так и внутри объекта. Развитием данного направления активно занимаются авторы данной статьи в тесном сотрудничестве с А. А. Красовским.
К настоящему моменту закончена разработка базового алгоритма управления многомерным объектом, не имеющим математической модели. Алгоритм может служить основой при синтезе управления любым объектом независимо от его природы: экономики отрасли, производственного предприятия, инвестиционной компании и т. д.
Существующие возможности позволяют синтезировать алгоритм автоматизированного управления конкретным производственным предприятием или отраслью, что предполагает создание многомерного адаптивного регулятора с самоорганизующейся моделью, имеющего M входов и N выходов. Объект управления рассматривается как кибернетический "черный ящик". Регулятор состоит из наблюдательной и исполнительной частей.
Задача наблюдательной части - в автоматическом режиме формировать математическую модель, адекватную текущему состоянию объекта и происходящим в нем процессам. Эта модель позволяет прогнозировать состояние бизнес-процесса на некоторый промежуток времени и использовать ее в алгоритме оптимального управления для формирования комплекса управляющих решений на ближайшую перспективу. В исполнительной части формируется программа управляющих воздействий. В течение следующего промежутка времени по вновь поступившим данным о текущем состоянии ("выходам") объекта, алгоритм автоматически формирует новую модель, адаптированную к новому состоянию объекта. Таким образом, уменьшение естественных для систем рефлекторного типа априорных неопределенностей достигается за счет использования информации, получаемой в ходе управления и последовательных наблюдений доступных входных и выходных сигналов.
Существенным является то, что самоорганизация и оптимизация используется как в наблюдательной части, так и в исполнительной, а неполная определенность структуры объекта и изменчивость параметров не являются критическими для функционирования системы.
Разумеется, на настоящем этапе развития теории адаптивных регуляторов, ввиду отсутствия опыта создания систем управления объектами нетехногенной природы, подобные алгоритмы должны разрабатываться эксклюзивно применительно к реальному предприятию. Поэтому все этапы создания программы предполагают участие специалистов заинтересованной организации. Например, с их участием определяется: размерность объекта, то есть число существенных и численно измеряемых параметров его состояния и возможных управляющих воздействий ("входы" и "выходы"); выборка и агрегирование наиболее значимых производственно-экономических показателей работы предприятия; концепция критериев качества управляемого процесса.
Конечно, неразвитость количественных представлений процессов, происходящих внутри предприятий, служит определенным препятствием на пути внедрения методов математической теории управления в гуманитарную сферу. Однако можно указать примеры рыночных секторов, вполне продвинутых с точки зрения информационного обеспечения. К таковым относится рынок FOREX, где существует возможность получения многообразной информации в режиме on-line. Все участники торгов могут пользоваться распространяемыми в сети Интернет, выполненными на основе научно разработанных методов, результатами фундаментального, технического, компьютерного и даже психологического анализов. К сожалению, рефлективность финансовых рынков не позволяет сформулировать однозначные рекомендации по их интерпретации и выработке конкретных решений. Здесь алгоритм качественного осмысления всего многообразия информации может быть количественно интерпретирован в рамках теории экспертных систем, дающей методику отбора и учета мнений экспертов, позволяющей их оценивать и делать соответствующие выводы.
Другой отраслью, которая может считаться достаточно подготовленной для создания и использования систем автоматического управления, является кредитно-финансовая сфера. Значение и развитость финансовых рынков для экономики как мирового, так и регионального масштаба способствовали разработке обслуживающих его количественных методов финансового анализа. Жесткое регулирование и прозрачность банковских технологий благоприятствуют внедрению здесь алгоритмов адаптивного управления.
Тем не менее опыт наших контактов с муниципальными руководителями, руководителями крупных банковских организаций и производственных предприятий города показывает неготовность их к участию в разработке, финансировании инновационных проектов такого рода. Между тем выход на мировой уровень конкурентоспособности предполагает прогнозирование будущих требований рынка и подготовку соответствующих технологий. Особенно это касается российских софтверных компаний, имеющих квалифицированный персонал и претендующих на определенную долю мирового рынка специализированных программных продуктов. Без соответствующих вложений в инновационные предприятия, обеспечивающие технологические скачки как самих разработчиков, так и их клиентов трудно рассчитывать на то, чтобы занять достойные позиции в современном индустриальном мире.
Чем же объясняется отсутствие заинтересованности бизнеса в разработке соответствующих технологий, притом что первоначальные финансовые вложения в это дело (в сравнении с бюджетом крупной компании) чрезвычайно малы. Вероятная причина - неосведомленность специалистов гуманитарной сферы о возможностях существующих технологий. Сложившиеся в среде управленцев стереотипы ограничивают возможность восприятия подходов, выходящих за рамки традиционно принятых. Причина кроется в устаревшей системе подготовки кадров - как в России, так и за рубежом.
Такая система подготовки объясняется существующей традицией противопоставления гуманитарных и естественных наук. Это создает искусственное разделение сфер их применения и соответствующее предубеждение специалистов-гуманитариев, полагающих, что математические методы бесполезны при решении задач, учитывающих влияние человеческого фактора. Хотя можно считать доказанным, что все области человеческой деятельности подчиняются единым закономерностям материального мира и могут быть смоделированы математически. Одним из последних, ярких подтверждений этого является знаменитая формула расчета цены опциона на продажу Блэка - Шоулза, совпадающая с известным в теории тепломассобмена решением уравнения тепловой диффузии.
В заключение заметим, что контроллинговые технологии стоят на пороге революционных изменений, связанных с внедрением количественных методов в управление экономикой. Их повсеместное внедрение позволит, применяя адаптивное моделирование бизнес-процессов, численно, в ускоренном времени, проверять эффективность предполагаемых стратегических решений, избегая таким способом риска экспериментирования с реальным объектом и соответствующих финансовых потерь. При этом появится возможность апробации и сопоставления в виртуальном режиме действенности вертикальной и горизонтальной структур конкретного предприятия в выбранном сегменте рынка. Таким образом, самоорганизующаяся математическая модель конкретного производственного процесса может быть использована для его реальной самоорганизации, когда по результатам численного эксперимента, для освоения новых сегментов рынка, вносятся коррективы в организационную структуру действующего предприятия.
Если начало разработкам в этой области не положат отечественные производители программных продуктов, то через несколько лет подобные программы мы получим из-за рубежа и станем адаптировать их к нашим реалиям, но в этом случае нам будет отведена совершенно другая роль в мировом разделении труда, а именно та, которую мы занимаем сейчас.

DAM-системы: динамично развивающаяся отрасль корпоративного софтверного рынка

Павел Серафимович, CNews.ru
Быстрое наращивание объема цифровых данных, хранимых в корпоративной сети компании, часто создает трудности в поиске необходимых данных. Согласно оценке экспертов, средний пользователь тратит десятую часть своего рабочего времени на работу с файлами. При этом возможности реляционных баз данных общего назначения ограничены. Пользователю часто требуется не только просто сохранить, найти или извлечь необходимую информацию. Кроме этого, нужно сохранять метаданные к изображениям, аудио- и видеофайлам, отслеживать их версии и права доступа к ним, конвертировать их в различные форматы. Для выполнения всех этих операций предназначены системы управления цифровыми архивами (digital asset management, DAM).
DAM-системы являются относительно новым видом корпоративного ПО. Тем не менее, согласно прогнозу маркетинговой компании Meta Group, в 2004 году 95% компаний из списка 2000 крупнейших компаний мира развернут у себя корпоративные DAM-системы. А ведь еще пять лет назад компания COCA-COLA не смогла найти подходящую DAM-систему и была вынуждена разрабатывать свою собственную. Однако два года назад, столкнувшись с необходимостью параллельной архивации разнородных данных, COCA-COLA приобрела у IBM продукт Content Manager (раньше он назывался Digital Library). За последние два года предложение на DAM-рынке значительно расширилось. Однако этап становления этого сектора софтверного рынка еще не завершен. Об этом можно судить хотя бы по разбросу стоимостей DAM-систем у ведущих поставщиков. Компания Canto, например, предлагает однопользовательский продукт Cumulus, предназначенный для фотографов и дизайнеров, за $99.95. Стоимость же корпоративной DAM-системы от Canto начинается с $35 тыс. для двадцати пользователей. У компании Artesia стоимость большинства проектов по развертыванию DAM-систем превышает $100 тыс. Корпорация IBM в основном занимается DAM-проектами, стоимость которых колеблется между $250 тыс. и $5 млн.
По оценке маркетинговой компании IDC, объем DAM-рынка увеличится к 2005 году до $1.8 млрд. со $117 млн. в 2000 году. Такому стремительному росту рынка способствовали, в частности, как это ни печально, события 11 сентября прошлого года в Нью-Йорке. Сейчас службы национальной безопасности в США испытывают большие трудности в систематизации и анализе огромного количества данных, получаемых с видеокамер, установленных в общественных местах.

Аналитики отмечают, что в конце прошлого года началась консолидация DAM-рынка. Это выразилось в нескольких крупных поглощениях и установлении новых партнерских связей. В частности, компания Documentum приобрела компании Bulldog и BoxCar. Это позволило Documentum уйти от своей первоначальной ориентированности на управление в основном веб-контентом и стать крупным игроком на рынке систем Enterprise Content Management. В отличие от Documentum, компания Interwoven придерживается другой стратегии. Она сохраняет веб-ориентированность своих продуктов для управления контентом, но предусматривает возможность их расширения продуктами от других поставщиков. В связи с этим Interwoven заключила соответствующие партнерские соглашения с компаниями Artesia и IBM.

По мнению MetaGroup, в ближайшее время DAM-системы будут развиваться по нескольким направлениям. Во-первых, к 2004 году большинство DAM-систем будет построено на основе серверов приложений, соответствующих спецификации Java 2 Enterprise Edition (J2EE). Это, в долгосрочной перспективе, удешевит и сделает более гибкой разработку DAM-систем. Во-вторых, будут предприняты шаги по интеграции DAM-систем со средствами создания контента. Два основных игрока на рынке средств создания контента - компании Avid и Quark - пока предлагают закрытые решения, не предусматривающие возможности интеграции с продуктами других поставщиков. Ожидается, однако, что вскоре обе компании последуют примеру другого крупного участника этого сектора рынка - компании Adobe, предлагающей открытые решения Photoshop и Illustrator, и сделают свои продукты более открытыми. Кроме этого, в будущем DAM-системы должны быть более тесно интегрированы с платформой Macintosh, на которой по-прежнему создается наибольший в мире объем рукотворного контента. В-третьих, предполагается, что в дальнейшем DAM-системы будут гибко вписываться в рабочие циклы компании и предоставлять более обширные возможности настройки DAM-системы под конкретный проект. Сложность рабочих циклов в крупнейших медиакомпаниях и сегодняшняя неспособность DAM-систем учитывать эти сложности, например, условия контрактов, гонорары актеров, права интеллектуальной собственности, пока препятствуют проникновению DAM-систем на этот многомиллионный рынок.


Для удовлетворения растущих потребностей пользователей DAM-системы в ближайшее время, по мнению экспертов, должны приобрести новые функциональные возможности. В частности, поисковые системы, кроме традиционного поиска по ключевым словам, должны предоставить возможность поиска по фрагменту изображения или нескольким нотам песни. С другой стороны, для полноценного использования DAM-систем необходимо улучшить существующую IT-инфраструктуру. Например, в компании COCA-COLA большинство пользователей вынуждены использовать DAM-систему лишь в качестве каталога, так как IT-департамент компании считает, что внутрикорпоративная сеть не выдержит пересылки больших объемов данных. Поэтому сейчас, например, найдя необходимое ему изображение в хранилище компании, сотрудник посылает заказ в соответствующую службу. Через некоторое время ему по почте присылают заказанное изображение на CD.

Кроме компании COCA-COLA, удачным было развертывания DAM-системы в автомобильном концерне DaimlerChrysler. Концерн работает со множеством рекламных агентств. Изображения автомобилей и сопутствующая маркетинговая информация хранятся в различных базах данных, часть из которых находится в DaimlerChrysler, часть - в рекламных агентствах. С помощью DAM-системы от компании Artesia удалось объединить данные с различных сайтов DaimlerChrysler, из множества печатных изданий и рекламных агентств. Директор департамента е-коммерции DaimlerChrysler Билл Вэдон (Bill Whedon) приводит следующий пример использования DAM-системы: .

Американская футбольная лига (National Football League, NFL) также использует на своих сайтах возможности DAM-системы, в частности, для ограничения доступа к контенту. Компания WebWare сопровождает несколько сайтов NFL. Один из сайтов предназначен для зарегистрированных спортивных журналистов. Зайдя на него, можно скачать, например, фотографии игроков и тренеров. На сайте для рядовых пользователей можно получить фрагменты игр с низким разрешением. Для получения по почте изображения с высоким разрешением в виде фотографии пользователь должен послать соответствующий заказ. В то же время существует B2B-система, в рамках которой коммерческие партнеры NFL могут скачать те же изображения с высоким разрешением.

IT консалтинг - статьи

Аддитивная концепция устойчива и эффективна при постоянно меняющихся внешних и внутренних условиях.

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

Аддитивная концепция:

информационная система дополняет человека (отсюда и название - аддитивная).

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

Для чего вообще нужны концепции?

Попробуем ответить на этот вопрос другим вопросом: каким Ваше будет предприятие через 10 лет? Какие свойства ERP системы будут тогда востребованы? В общем, никто не сможет четко ответить на задачу с такой отдаленной перспективой. При этом предприятие должно быть уверено, что и в отдаленном будущем имеющееся у него программное обеспечение (ПО) будет способствовать развитию бизнеса, и только такое ПО востребовано. Так вот, для того, чтобы конструировать систему, в т.ч. для целей, которые неясны, и задач, появление которых мы не можем предвидеть, и существуют концепции.
Пример: Начинаем автоматизировать маленькое предприятие, в нем три человека, один компьютер. Количество клиентов - 10, наименований товара - 20. Вопрос - какую архитектуру данных выбрать? Обратимся к концепции. Во-первых, определимся, что предприятие будет развиваться (т.е. мы его не закроем через месяц). Во-вторых, отрасль, в которой мы сейчас работаем - это тысячи наименований, хотя на данный момент у нас всего 10 (например, мы продаем исключительно мыло, видов мыла у поставщика может быть 100, ну 200 максимум, однако, если смотреть шире - зубная паста, щётки, гели и т.п., что называется хозтоварами, а это уже десятки тысяч наименований). Следовательно, исключить то, что мы будем представлять весь ассортимент, мы не можем так же как нельзя исключить, что со временем предприятие превратится в большую структуру. Тогда добавляем в концепцию постулат, что наша ERP-система должна поддерживать произвольное количество наименований товара и рабочих мест, плюс должна быть нетребовательна к сети. Иначе, как создавать филиалы, если каждый из них потребует прокладки высокоскоростной сети на многие километры? Теперь очевидно, что самая подходящая архитектура - Клиент-Сервер. Вот и решение!
Рассмотрим внимательно, что мы сейчас сделали. Сперва мы определили некие общие параметры, которые присущи или будут в присущи будущем нашей системе (концепция), затем приняли решение относительно конкретного вопроса (выбрали архитектуру данных). В дальнейшем, во время решения конкретных задач, мы должны будем применять такие методы, которые бы не противоречили концепции. Заметьте: мы уже решаем задачи, о которых еще ничего не знаем.

Имитационная концепция: имитирует реальное строение предприятия.

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

Имитационная

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

Почему же очевидный на первый взгляд способ решать большую и сложную задачу по частям не гарантирует стабильной работы системы?

Чтобы ответить на этот вопрос, давайте рассмотрим предпочтительную и более современную аддитивную концепцию построения ERP систем.

Поставим задачу:

Необходимо, чтобы система "человек - компьютер" функционировала с минимальной энтропией.

Энтропия на уровне компьютера.

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

Энтропия на уровне человека.

Т.к. мы уже определили, что на уровне компьютера энтропия минимальна, то ответ однозначен - источником роста энтропии в системе является человек! Это он ошибается, не может быстро переключаться с одного дела на другое и плохо воспринимает более 9-ти объектов одновременно.



Как свести к минимуму человеческие ошибки (уменьшить энтропию системы)?

Во-первых, количество возможных решений должно быть максимально ограничено.

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


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

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

Итак, выпишем цепочку, при которой

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

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

мы выяснили, что люди организовываются

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

Теперь посмотрим, что происходит, если человеческая система начинает укрупняться. Представим одного рабочего. Допустим, он ошибается крайне редко и выпускает 1 бракованную деталь к машине на 1000 не бракованных. В общем, мелочь. Но как только узлов в машине становится порядка 1000, и их так же делают рабочие с таким же процентом брака, то окажется, что в каждой машине что-нибудь, да не работает. Этот пример говорит о том, что если такая система увеличивается, её энтропия тоже возрастает, и нужно принимать меры к её уменьшению. Иначе система просто умрет - кому нужны 100% бракованных машин?

Как ведет себя энтропия при росте системы?

Давайте отвлечемся и посмотрим, для чего человек (человечество) все более специализируется и почему большие системы менее устойчивы, чем малые.
Во-первых, базовым понятием для систем вообще является ЭНТРОПИЯ, мера беспорядка. Чем выше организация, тем меньше энтропия. Критерием организованности является следующее определение: уровень организации тем выше (а энтропии тем меньше), чем больше свойства целого отличаются от простой суммы свойств. Т.е., если труд организован (энтропия минимальна), то два человека, работающие вместе, сделают больше, чем оба, но работая по отдельности. С этой самой энтропией мы и намерены бороться.
Во-вторых, основным средством для уменьшения энтропии является ИНФОРМАЦИЯ. Приведем пример: на складе есть товар, но продавцы не имеют информации об остатках на складе. Нет информации- нет отгрузок, система не работает, хотя и кладовщики, и продавцы готовы выполнить свои обязанности.
В-третьих, человек, существо хоть и разумное, но склонное к ошибкам. Оказывается, что корректно выполнить 100 простых операций проще, чем одну, но в 100 раз более сложную. Это свойство человека и заставляет людей специализироваться, а предприятия состоять из отделов, ибо быть специалистом по маркетингу еще можно, и то в какой-нибудь отрасли, а вот быть одновременно специалистом по маркетингу, документообороту и управлению очень трудно, даже невозможно.
В-четвертых, люди способны работать с ограниченным набором данных (объектов). В среднем, человек нормально воспринимает 5-9 объектов. Если объектов больше, человек гораздо чаще ошибается. Применительно к ERP-системам, это означает, что интерфейс пользователя должен содержать как можно меньше окошек с данными, опираясь на которые пользователь принимает решение.
Пример: Пусть предприятие продает леденцы. Пришел покупатель, говорит: вот деньги, хочу леденцов на 50 тыс. руб. Продавец видит остаток на складе и, если товара достаточно, то он отгружается; если товара нет, об этом сообщается клиенту, и как-то этот вопрос улаживается - это нормальная работа. Если же продавец видит остаток на складе на 1 число текущего месяца и движение по данному товару за две недели, то чтобы принять решение об отгрузке он должен будет вычесть всё, что напродавал он сам и его коллеги за эти две недели и прибавить то, что пришло за это время на склад. Представьте, сколько места на экране должны занимать все эти цифры! Причем продавцу придется вычислять количество леденцов либо в уме, либо на калькуляторе, но в любом случае, количество ошибок возрастёт многократно. Заметим, что и в первом и во втором примере информация, в общем, эквивалентна, но человеку гораздо проще работать, если все представлено в удобном виде.

Концепции построения ERP-систем на предприятии

Директор ООО "Софтоматика"

13 Апрель 2004 г

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

Применительно к аддитивной и имитационной концепциям.

Посмотрим, как все это относится к нашим концепциям.

IT консалтинг - статьи

IT-планирование: как добиться успеха

Экономика в режиме Internet Time - это дополнительные трудности при планировании бизнеса. Слишком часто происходят изменения, которые полностью переворачивают рынок IT. Успеха же добиваются те компании, которые готовы к таким, подрывающим рынок, изменениям. То есть не занимающиеся прогнозированием перемен, а полностью готовые к ним. В этом смысле разумнее составлять несколько планов и выбирать лучший. Именно этим обусловливается прагматичный подход при поиске и выявлении всех рисков. Поэтому время реализации должно быть минимальным. И значит, необходимо искать решения, использующие минимальное количество ресурсов. Этими аспектами и необходимо руководствоваться при составлении IT-плана.

IT-планирование: новые перспективы

#1(13)/2004
Каждая отрасль экономики имеет свою специфику, которую необходимо учитывать при применении теоретических основ этой важной науки. Информационные технологии - один из самых бурно развивающихся рынков. Время жизни продукта здесь короче, а процесс морального и технологического старения стремителен. О каком долгосрочном планировании может идти речь, спросите вы? И все же это возможно.
При IT-планировании необходимо учитывать два основных аспекта менеджмента. Помимо традиционных бизнес-целей, следует понимать что такое IT-менеджмент. Не секрет, что наши вузы выпускают сотни экономистов, менеджеров и маркетологов. Но знакомы ли выпускники с IT-технологиями и их спецификой? Ответ очевиден, и он вряд ли вас обрадует. Следовательно, на каждом предприятии планированием должны заниматься одновременно два звена. Первое - традиционное экономическое. А второе - IT-менеджмент. В качестве последних должны быть специалисты, превосходно ориентирующиеся в информационных технологиях, перспективах их развития и способные прогнозировать хотя бы относительно недалекого будущего. Ведь вряд ли экономист сможет отдать предпочтение процессорам AMD или Intel. Но и технический специалист не оценит степень прибыльности вложения капитала.
Специалисты считают, что на рынке IT полученные средства должны распределяться следующим образом: 80% вкладываются в развитие и поддержание бизнеса и лишь 20% составляют доходную часть. Это еще одна особенность высоких технологий. Правда, существует и другой подход к ведению бизнеса - отсутствие всяких планов. Но такая практика пагубна. В первую очередь она противоречит пропорции 80-20%, о которой говорилось выше. Отсутствие четкого плана тормозит развитие предприятия. Вы уже не можете точно сказать, какую долю составляют вырученные средства за долгосрочный период. Сколько из них нужно пустить на развитие и сколько составит прибыль. Предприятия без IT-планирования не смогут долго существовать.
Ознакомимся, для примера, с одной из методик IT-планирования. Она носит название "высокоскоростное планирование" (IT - быстроразвивающаяся область высоких скоростей) и состоит из шести этапов.

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

Второй этап высокоскоростного IT-планирования - так называемое предположение. Конечно, заманчиво развивать нейрокомпьютеры или вложить средства в плазменные мониторы. Но стоит ли делать это? Вполне вероятно, что на рынке уже есть весьма перспективный продукт, который набирает ход. И надо ли заниматься предсказаниями успешности заманчивой, но пока далекой от практического применения технологии? Разумное IT-планирование предполагает реальную оценку рынка, которая должна свести к минимуму экономические риски.

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

Далее следует выбор стратегии. Существует соответствующий термин - Internet Time. Это время, в котором существует рынок высоких технологий. Оно характеризуется высокой степенью изменчивости и минимальной уверенностью в будущем. Не слишком оптимистично, но с 2000 года этот термин полностью утвердился для характеристики IT. Стратегический выбор должен уловить правильный баланс сочетания традиционного IT-планирования и необходимости планирования в режиме Internet Time. Для чего следует рассмотреть будущие инвестиции с нескольких точек зрения. Можно выделить несколько типов проектов. Авантюрные, с быстрой отдачей; систематические (усовершенствование того или иного продукта, занимающего стабильные позиции на рынке); проекты, ориентированные на целевую аудиторию (здесь есть гарантия того, что успешный продукт будет востребован определенным предприятием, благодаря своей уникальности) и ряд других. В аспекте Internet Time следует сделать правильный выбор, опираясь на размер инвестиций в проект.

И наконец, последний этап планирования - выбор и действие. Здесь разрабатывается конкретный план действий, направленный на достижение цели. Рынок оценен, продукт выбран, цели определены - осталось только их достичь.

Как определить стратегию бизнеса

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

Перспективы роста

Производство

Стоимость операций

Использование ключевых ресурсов

Ожидаемое сотрудничество

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

Технологическая стратегия предприятия

Стратегический IT-план

IT-архитектура

Новое IT-направление должно обрести свое место в структуре вашей компании. При этом надо учитывать, насколько удачно будет вписываться новинка в существующую структуру, каким образом можно снизить затраты на производство, доставку и реализацию при помощи имеющихся ресурсов. На данном этапе следует максимально использовать все возможности, которыми располагает предприятие для достижения новых целей, а в случае необходимости - принять решение о соответствующей модернизации производства.
Стратегический IT-план - это распределение ресурсов. Это один из ключевых этапов. Ведь именно в такой момент делается выбор, как тратить деньги и какие проекты заслуживают инвестирования, а какие нет. Здесь в большей степени присутствует тактика, нежели стратегия. А потому руководству компании уже должен быть представлен план, иллюстрирующий направление инвестиций в IT, цели, размеры инвестиций, сроки окупаемости. При этом основное внимание должно уделяться именно максимальной выгоде, которое получит предприятие. Составные части IT-плана - это сформировавшийся оперативный план и бюджет. Классический стратегический план - это ответ на три вопроса: "Куда мы идем?" (видение вопроса), "Как добиться этого?" (стратегия) и "Что нам надо для этого делать?" (последовательность конкретных шагов, направленных на достижение целей).
Создание IT-архитектуры - это развитие структуры и принципов руководства для нового IT-продукта. Основной выигрыш от ее разработки - осознание четкой последовательности действий и методов, которым будут следовать сотрудники при введении новинки. Можно назвать это алгоритмом. Разумеется, при этом архитектура должна быть документально подтверждена. В документации должно содержаться объяснение того или иного выбора и доказательство ее оптимальности. Фактически, это план "вписания" технологического производства (или нового подразделения) в структуру вашего предприятия. Но уже на более детальном уровне, нежели раньше. Здесь уже не задается вопрос, как потратить деньги? Этот этап - ответ на вопрос, как все организовать.

Новые времена - новые нравы

Скорость развития событий на IT-рынке будет проще учитывать, если принять во внимание следующие моменты:

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

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

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

Разрабатывать несколько сценариев для достижения цели, а не вкладывать все усилия в один "наиболее вероятный" сценарий развития событий

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

Максимально быстро переходить от этапа "знаю как" к этапу "делать"

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

Соблюдать пропорцию 80 - 20

Об этом говорилось выше.

IT консалтинг - статьи

Фактор 1. Квалификация и потенциал персонала

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

Фактор 2. Четкое понимание целей проекта всеми его участниками

Ловушка 2: После завершения проекта Вы не получили того, чего ожидали в начале.
Достаточно часто в жизни, да и в бизнесе людям свойственно приписывать продуктам и услугам, которые они хотят приобрести, свойства которыми оные не обладают. И наоборот некоторые продукты и услуги обладают такими свойствами, о которых потенциальные Заказчики даже представления не имеют. Как правило, клиенты могут обратиться с запросом: продайте нам услугу «Постановка и автоматизация бюджетного управления» и давайте начинать работать завтра. И представьте себе, что, соблазнившись на деньги, Исполнитель соглашается и начинает проект. Консультанты и сотрудники Заказчика классно работают и в сжатые сроки выдают результат на 120% (можно даже на 200% это сути не меняет), но руководство, заказавшее проект недовольно результатами. Начинается анализ причин недовольства руководителя результатами проекта. И что оказывается, недовольство было вызвано не качеством и скоростью работ, а то, что на выходе руководитель получил не то, что ожидал. Так в чем же причина? Ответ очень прост, все произошло из-за того, что перед началом работ не были совмещены представления Исполнителя и Заказчика о тех результатах, которые получит Заказчик по окончанию проекта. Как уже было сказано выше, всем нам свойственно приписывать услугам свойства, которыми они не обладают и соответственно в качестве результатов они могут ожидать от услуг эффектов, которые могут находиться даже не в управленческой сфере, а в юридической и политической. Поэтому, не пройдя этап, после которого можно сказать, что исполнитель и Заказчик понимают результаты одинаково – реализация проекта становится лотереей, могут оба выиграть, а могут оба и проиграть.
Что вас ждет: К сожалению, исход в таком случае достаточно печальный: так как поставленные задачи выбранным способом не решились, у вас автоматически возникает недовольство работой консультационной компании, плюс, потраченные материальные и трудовые ресурсы, плюс, внедренная технология, с которой «надо как-то дальше жить». В принципе, на нашей практике были случаи, когда предприятия, тем не менее, продолжали двигаться дальше и по истечении времени находили внедренную систему полезной и необходимой. Но все, же лучше решать проблемы по мере их поступления, четко расставляя приоритеты и понимая что, зачем и почему именно так мы делаем в данный отрезок замечательной истории нашей замечательной компании...
Каким образом учитывать этот фактор и влиять на него:
Обычно, предприятия, обращающиеся с первоначальным запросом за консультационными услугами к специалистам, запрашивают конкретное решение, которое им (по их глубокому разумению) необходимо. Очень часто, запрос формируется конкретным образом: нам необходимо бюджетирование, нам нужен такой-то программный продукт, нам необходимо провести тренинг топ-менеджмента по лидерству и уволить нескольких человек. При этом, вся «предыстория» обычно умалчивается, принявшему решение о задействовании управленческих консультантов или специалистов по внедрению того или иного продукта все предельно ясно. Еще бы, скорее всего, та проблема (точнее ее видимые негативные проявления), которая заставила на это решиться, обдумывалась не одну ночь или месяц, был проведен глубокий (на самом деле, очень поверхностный) анализ решений, предлагаемых рынком. Но бывалых консультантов этим не смутишь: будьте готовы к тому, что вас будут очень подробно (в дружественной и доверительной обстановке) расспрашивать о вещах, с вашей точки зрения, к проблеме совершенно не относящихся. Не все так просто, недаром в современном бизнесе есть своего рода «разделение труда» - вы управляете своим предприятием, а есть компании, которые специализируются на том, чтобы помогать вам управлять наиболее эффективным образом. Поэтому не спешите с выводами и выбором конкретного решения: доверьтесь консультантам, не стесняйтесь выдавать поток проблем, которые вас мучают «без анализа». Известный факт, что любой, даже самый квалифицированный специалист порой не в состоянии увидеть банальных причинно-следственных связей, которые прямо-таки бросаются в глаза консультанту, который, хоть и не обладает соответствующим знанием специфики данной области, но «съел собаку» на подобных проектах и при общении с такими «озабоченными» будущим своей компании специалистами. Чем более подробную картину вы предоставите, тем больше шансов на то, что выбранная технология будет соответствовать решению поставленных вами задач.

Фактор 3. Соответствие философии вашей компании философии консалтинговой компании

Не секрет, что успешное выполнение проекта должно проходить «на одном дыхании», когда есть взаимный интерес сторон. Внешние консультанты и ваши сотрудники должны стать «соратниками» на период выполнения проекта (а иногда, и не только), тогда любые сложности возможно преодолеть. А соратниками люди становятся только при условии совпадения ценностей, взглядов и пр. Это достаточно тонкий психологический момент и определить эту область одним словом нельзя: это может быть и стиль ведения бизнеса, идеология и приоритеты руководства, корпоративный дух и корпоративная культура, мы обозначим это как «общефирменная философия». Вы можете считать, что у вас в компании пока нет корпоративной культуры, но, тем не менее, определенная «надстройка» на уровне менталитета, присущая вашей компании, все же уже есть. Если подобная "надстройка" консалтинговой компании окажется Вам чуждой, то волей-неволей, Вы будете внутренне отторгать те рекомендации, конкретные действия, которые будут исходить от консультантов, не смотря на то, что "грамотные и уважаемые люди" будут произносить "правильные и разумные слова".
Ловушка 3: Проект идет с трудом, затягивается и после его завершения, внесенные изменения «не приживаются», так как не соответствуют ценностям компании, не вписываются в характер и темпы ее развития.
Что вас ждет: здесь сложности начнутся с первых же дней реализации проекта. Вам будут не понятны те или иные действия специалистов консалтинговой компании, со стороны ваших сотрудников не проснется необходимый для реализации таких проектов энтузиазм и вовлеченность. В конечном итоге проект может «затухнуть».
Каким образом учитывать этот фактор и влиять на него:
Нет конкретного «индикатора», позволяющего определить, насколько ваша компания и компания, предоставляющая услуги по управленческому консультированию, близки по духу. Обычно, такие вещи очень хорошо чувствуются, когда происходит «очное» общение, причем именно в офисе той компании, которую вы «присмотрели» в качестве консультанта. Если на протяжении всего общения не только вы, но и ваши коллеги будете испытывать напряжение, а скорее даже отчуждение того, как и что вам будут говорить, то стоит хорошо задуматься, прежде чем обратиться к услугам данной компании. В делах консультирования, также как и в обычных человеческих отношениях, должен присутствовать элемент доверия и понимания...
Кстати говоря, язык общения очень показателен в этом смысле – он может принимать различные формы для выражения в сущности одного и того же. В каждой компании есть свой "птичий" язык. Есть компании, в которых менеджеры перекидываются друг с другом обрывочными фразами директивными характера, им достаточно дать "набросок" мысли – и все друг друга понимают, и время не теряется. У других – наоборот – принято говорить много, витиевато, показывать друг другу проблему с разных сторон, не забывая при этом отвешивать друг другу "реверансы". Вообще говоря, специалисты – профессионалы должны подстраиваться под разные стили общения – но если они совпадают изначально – это поможет избежать многих издержек общения.
Еще один важный момент – одинаковый темп выполнения работ, и принятия решений. Любой консалтинговый проект означает выполнение разных работ двумя сторонами, например, заполнение анкет, подготовка документов и пр. На практике плохи оба отклонения: и если консультант работает медленнее, чем того ожидает заказчик, и наоборот, если заказчик медленнее выполняет свою часть работы (подготавливает информацию, согласовывает результаты), чем того ожидает консультант (да-да, при наличии определенной технологии консалтинговых работ бывает и такое!).
В смысле ценностей компаний очень полезно сравнить миссии – конечно не содержание, с упором на специфику бизнеса, а на тон, акценты и т.п. Хотя в нашей практике был случай, когда мы в процессе общения с одним клиентом – крупной лизинговой компанией, ощущая поразительное взаимопонимание и "взаимовосприятие", поразились, когда познакомились с их миссией – формулировка, слова, и конечная общая цель – абсолютно совпадали – только для них средство достижения поставленных целей – предоставление лизинговых услуг, для нас – постановка систем управления.

Фактор 4. Ваши материально-трудовые ресурсы

Начинать проект, не просчитав достаточно ли необходимых ресурсов, то же самое, что идти на месяц в поход, по маршруту, где нет подножного корма с одной банкой тушенки. Только из-за того, что первоначально не хочется тратить время на расчеты, а достаточно ли будет одной банки для питания в течение целого месяца? И что в итоге получается, компьютеры оказываются недостаточно мощными, чтобы установить необходимое программное обеспечение, системное программное обеспечение устарело, а у сотрудников, которых выдвинули для реализации, а в дальнейшем на поддержку и развития результатов проекта нет резервов свободного времени для этих работ. Тут необходимо либо брать дополнительных сотрудников, либо производить ротацию имеющихся сотрудников, но проект - то уже идет и времени на подбор и обучение персонала нет. Простой пример на заводе работают 30 человек в бухгалтерии, компания собирается поставить у себя управленческий учет и бюджетирование, но для выстраивания и автоматизации новых процессов не менее трудоемких, чем бухгалтерский учет, руководство не сформировало штат сотрудников (даже из нескольких человек), которые будут заниматься управленческим учетом. Начинаются хаотичные перераспределения функций, которые, как показывает практика, приводят только к склокам в коллективе и провалу проекта. Очень наглядное изображение пословицы «семь раз отмерь, одни раз отрежь».
Ловушка 4: Вы начинаете проект, не просчитав все необходимые материальные ресурсы и достаточность свободного рабочего времени, а значит, практически в 90% случаях, никогда его не закончите.
Что вас ждет: в процессе реализации проекта реальный бюджет окажется намного больше запланированного. Проект по постановке системы управления реально может стать своеобразной "черной дырой" в денежном выражении. Не менее опасно для предприятия недооценить временные ресурсы своих сотрудников, которые будут задействованы в проекте. Если их время будет спланировано не правильно, то текущая деятельность предприятия парализуется, так как все силы будут брошены на "новый проект".
Каким образом учитывать этот фактор и влиять на него:
Любая консалтинговая компания перед началом проекта проведет с той или иной степенью детализации так называемое предпроектное обследование, в процессе которого будет составлен бюджет проекта. В такой бюджет будут включены примерные затраты за непосредственно консультационные услуги, часто – предложения по обучению сотрудников, оценка "железных" ресурсов, которые вам наверняка понадобятся. Как показывает практика, реальные затраты на проект никогда не исчерпываются той цифрой, которая будет сформирована вначале. Самое первое, с чего нужно будет начать, после того, как вам стала известна примерная сумма затрат за консалтинговые услуги, так это подробный График занятости ваших сотрудников на время исполнения проекта. Составить его вовсе не так просто как может показаться на первый взгляд. Это должно быть вашей совместной работой на "допроектной" стадии переговоров с консалтинговой компанией, которая должна четко сориентировать вас, какие сотрудники, для чего и как часто понадобятся. Далее, исходя из приоритетов вашей текущей работы, вы должны четко распределить загруженность ваших сотрудников. Так как времени никогда и не на что не хватает, то здесь также есть "свои ухищрения". иногда консалтинговые предлагают проводить тренинги и корпоративное обучение загородом в отвлеченной обстановке.

Фактор 5. Соответствие выбранного управленческого решения реально стоящей перед вами задаче

К консультантам, как и к врачам, реальные люди приходят с проблемой. Для профилактики пока еще никто к консультантам не обращался. Учитывая то, что сейчас большинство российских компаний находятся на фазе роста, которая является самой тяжелой фазой с точки зрения управления, то общий характер обращений в конечном итоге сводится к тому, чтобы удержать гармоничный рост предприятия и одновременно сохранить управляемость компанией. В процессе роста и развития перед предприятием встает множество задач, а соответственно и проблем. В этой связи особенно важно определить достоверные причины вызванной проблемы. Очень часто приходится сталкиваться с ситуацией, когда компании, обращаясь за помощью к консультантам, уже четко знают, что именно те должны сделать.
В практике нашей компании был случай, когда нас пригласили автоматизировать операционную деятельность. Вскоре мы осознали, что основная проблема клиента не в отсутствии автоматизированной системы учета операционной деятельности, а в том, что у клиента элементарный бардак на складе (компания торговала многотысячным ассортиментом запчастей). В результате все уперлось в грамотную разработку нами бизнес-процессов на складе, включая создание должностных инструкций. В итоге нам удалось объяснить это клиенту, и мы двинулись дальше. Постановка задачи на АСУ, технический проект, его реализация... А заказчик в этот момент принял решение развивать принципиально новую форму торговли – через супермаркеты (а раньше 90% продаж он осуществлял оптом). Ну и нас мило попросил – ребята, заложите-ка еще в АСУ возможности работы через супермаркет. Как, с какими аппаратами, в каких объемах, сколько супермаркетов, какая оргструктура будет для нового направления? Ну, так вы же специалисты, вот давайте и подскажите, обсудим, а потом и реализуете. И чем дальше, тем больше эта проблема организации супермаркетов стала выходить на первый план, затмевая собственно задачу автоматизации текущей операционной деятельности. В итоге проект ничем и не завершился, стороны поняли, что каждая хотела другое от проекта, и мы расстались.
Ловушка 5: В процессе проекта вы осознаете, что проблема лежит гораздо глубже и для ее решения требуется совершенно другой способ.
Каким образом учитывать этот фактор и влиять на него:
Самый главный совет: руководству предприятия отойти от постановки конкретной задачи к осознанию проблемы в комплексе. На самом деле, на первоначальном этапе общения – это и есть основная задача консультанта.

Фактор 6 Способность ваших сотрудников объединяться в команду

Ловушка 6: В процессе проекта обнажаются и обостряются все негативные моменты взаимоотношений между сотрудниками, безобидный на первый взгляд проект дает толчок к расколу внутри компании, возникает «сопротивление» проекту.
Что вас ждет:
То, что вас ждет, в худшем случае, можно обозначить одним словом: саботаж. Конечно, это будет происходить более интеллигентно и завуалировано (хотя, не всегда…), но факт остается факт: все «болезни» внутри коллектива имеют свойство обнажаться и если это застанет вас врасплох, то на протяжении всего проекта ваше внимание (и внимание консультантов) будет постоянно переключаться на урегулирование вспыхивающих конфликтов интересов.
Каким образом учитывать этот фактор и влиять на него:
Не смотря на то, что этот фактор мы указываем в конце, он, несомненно, самый важный в процессе любого проекта, влекущего за собой вмешательство в систему управления. Если вы переоцените собственных сотрудников с точки зрения их умения сплачиваться в команду и эффективно вырабатывать командные решения – это сведет на нет все ваши предыдущие усилия. Поэтому именно перед началом любого проекта необходимо проанализировать, какие проблемы у вас есть с точки зрения внутрифирменных коммуникаций. Причем, специалисты, непосредственно вовлеченные в проект, могут уметь прекрасно работать друг с другом, а проблема может крыться в отношениях того или иного сотрудника со своими непосредственными подчиненными, которые на этапе вмешательства в компанию консультантов могут никак не участвовать, но которым планируется «спустить» все нововведения «свыше». Обладают ли ваши менеджеры достаточным авторитетом и доверием подчиненных? Когда вы проанализируете психологическую подготовку своих сотрудников и коллег к проекту, у вас наверняка появятся определенные «дыры» и сомнения относительно будущей совместной работы, о них вам и нужно будет подробно рассказать компании, предоставляющей консультационные услуги. На основании этой информации уважающим себя консультантом будет выработана технология, позволяющая избежать разрушительных процессов и решить их конструктивными методами. Скорее всего, понадобится ряд корпоративных тренингов по выработке коммуникационных навыков у ваших сотрудников. Хотя опыт нашей компании показывает, что при определенном подходе, правильной организации проекта общение сотрудников в отвлеченной обстановке, направленное на развитие и рост компании выводит все внутренние конфликты на конструктивный уровень.
В идеале, проект по постановке системы управления – это лучший повод для того, чтобы сплотить команду, вовлечь менеджеров в процесс развития и выработать общекорпоративные ценности и установки.
document.write('');

Ловушки управленческого консультирования

, , журнал "IT Manager" #14(2)/2004
Как застраховать себя от неудачных последствий вмешательства в систему управления? В проекте по постановке системы управления есть факторы, на которые можете и должны влиять ИМЕННО ВЫ, в противном случае вы рискуете угодить в ЛОВУШКУ...
Сегодня достаточно часто приходится сталкиваться с ситуацией, когда успешная динамичная компания под влиянием происходящих изменений становится неуправляемой, а существующая система управления более не соответствует масштабам и потребностям бизнеса. Развитие бизнеса и апгрейд системы управления – два взаимосвязанных параллельных процесса: хотите держать руку на пульсе современного бизнеса – тогда вам не избежать вмешательства в собственное управление и общения со специалистами по управленческому консультированию. Этот процесс, давно ставший традиционным для западных компаний, теперь становится закономерным и в России. С одной стороны – прибегать к помощи внешних специалистов для консультаций по оптимизации системы управления - это неизбежно, с другой стороны – чревато опасными последствиями.
Недаром говорят, что один проект на предприятии равен трем пожарам. Проекты по оптимизации системы управления обычно не только дорогостоящи и длительны по времени, но и являются высоко рисковыми мероприятиями, а иногда могут принести предприятию больше вреда, чем пользы. Тем не менее, хоть и не на 100%, но обезопасить себя можно. В проекте по постановке системы управления есть факторы, на которые может влиять только руководитель, в противном случае он рискует угодить в ловушку. Не смотря на их кажущуюся очевидность, очень редко инициаторы проектов по внедрению новых управленческих и информационных технологий рассматривают эти факторы в комплексе и придают им должное значение. Если на предварительном этапе вы не учтете какой-то из этих факторов, то вы рискуете угодить в ловушку, даже если в процессе проекта по постановке (и автоматизации) системы управления вы выбрали компанию, занимающую первые строчки рейтингов, или выбрали ее по рекомендации знакомого, успешно воспользовавшегося ее услугами. Как ни странно, но успех в данном мероприятии зависит в большей степениот вас, от вашей заинтересованности и готовности к проекту, нежели от квалификации выбранного вами партнера.
Статья рассчитана на всех, кто заинтересован в развитии своего бизнеса, либо отдельного направления деятельности своей компании, причем реально занимаемая вами должность не имеет значения. Главное – вы именно тот человек, который стремится к успеху и хочет видеть конкретные результаты своей деятельности. В успешной компании обязательно должны присутствовать специалисты – «ведущие», которые указывают и прокладывают путь, их также называют «проводниками изменений». Если вы читаете эту статью, то почти наверняка для своей компании вы являетесь именно таким специалистом.
Далее мы выделим факторы, на которые Вам необходимо повлиять в процессе общения с консультантами в 6 групп. Чтобы проиллюстрировать их на практике, будут приведены практические ситуации, с которыми нам приходилось сталкиваться, мы покажем также типичные ошибки, которые были допущены предприятиями, приступающими к проекту по постановке системы управления. Авторы статьи не претендуют на разработку новой комплексной методики, позволяющей добиться успешных результатов в любом проекте по постановке управления, как уже было сказано выше, успех проекта зависит именно от вас. Мы предлагаем вам обратить пристальное внимание на несколько факторов от предварительной обработки которых до проекта напрямую зависит его конечный результат.

IT консалтинг - статьи

Методические рекомендации №1 "О порядке автоматизации отчетности по МСФО"

Валерий Чаусов, Генеральный директор компании Intersoft Lab
Заголовок данной статьи созвучен с Указанием Банка России №181-Т от 25.12.2003 "Методические рекомендации "О порядке составления и представления кредитными организациями финансовой отчетности". Выбор такого заголовка не случаен. Несомненно, что он носит несколько ироничный оттенок, и в то же время должен привлечь внимание сотрудников служб автоматизации российских банков. Действительно, в настоящее время сложилась несколько парадоксальная ситуация с вопросом "Как автоматизировать подготовку отчетности по МСФО?"
С одной стороны, сотрудники банков, ответственные за подготовку отчетности по МСФО, а также их руководство, понимают, что от Банка России большей детализации в плане рекомендаций по подготовке новой отчетности ждать не приходится. Поэтому банки? ранее не занимавшиеся этой задачей, активно приступили к изучению принципов МСФО и реальной работе совместно с аудиторами и консультантами. Те же банки, которые ранее уже составляли подобную отчетность, озабочены тем, как минимизировать свои затраты при подготовке отчетности по МСФО для инвесторов, зарубежных партнеров, а теперь еще и для Банка России.
С другой стороны, разработчики систем автоматизации для банков, даже те, которые уже давно декларировали свою готовность автоматизировать отчетность по МСФО, вдруг резко снизили активность по рекламированию своих решений. Несомненно, что и на них оказала влияние "конкретность" методических рекомендаций Банка России.
В связи с этим IT-службы банков оказались "между двух огней":

требования от бизнес-подразделений и своего руководства срочно предоставить эффективное решение поставленной задачи;

фактическое молчание или недоговорки по заданному вопросу от своих проверенных временем поставщиков систем автоматизации.

Компания Intersoft Lab уже накопила приличный опыт в области автоматизации отчетности по МСФО как в трактовке Банка России, так и в соответствии с классическими требованиями IAS и GAAP для банков, предприятий и финансово-промышленных групп. Но мы понимаем, что наши решения не являются применимыми абсолютно для всех банков, озабоченных поставленной задачей. Вместе с тем, опыт компании Intersoft Lab может быть полезен для служб автоматизации российских банков, которые еще не нашли адекватного решения данной проблемы.

Методические рекомендации IT-службам банков

Прежде чем принимать решение о способе автоматизации подготовки отчетов по МСФО, необходимо четко сформулировать требования к системе автоматизации. Цель выполнения этой работы - минимизировать расходы банка на автоматизацию отчетов по МСФО.
Это необходимо сделать, даже если в банке есть система для автоматизации отчетности по МСФО (например, система "Контур Корпорация") и даже если в банке работают опытные специалисты, не первый год выполняющие подготовку отчетности по МСФО с использованием MS Excel.
Вспомним, что Указаниями Банка России регламентирован лишь состав и вид отчетов по МСФО, а также общие рекомендации о порядке ее составления. Вторая часть необходимой информации содержится в методических рекомендациях специалистов, подготавливающих отчетность по МСФО для конкретного банка - будь они сотрудниками банка или аудиторами. Третья необходимая часть информации выявляется в результате анализа состояния систем автоматизации банка, содержащих первичную информацию, необходимую для подготовки отчетов.
Необходимо проанализировать все три перечисленных источника информации для того, чтобы сформулировать требования к системе автоматизации подготовки отчетов по МСФО для конкретного банка.
Для принятия решения о способе автоматизации отчетов по МСФО необходимо обратить во внимание следующее.
Известен состав отчетов по МСФО, которые потенциально могут быть автоматизированы:

консолидированный баланс;

консолидированный отчет о прибылях и убытках;

консолидированный отчет о движении денежных средств;

консолидированный отчет об изменении собственных средств акционеров.

Примечания к консолидированной финансовой отчетности, которые потенциально могут быть автоматизированы, поскольку содержат в себе таблицы с числовыми значениями. Примечаний насчитывается 29 штук, а входящих в них таблиц - 53.
Также известен состав исходной информации, требуемый для подготовки отчетов по МСФО:

балансы по РПБУ филиалов, дочерних банков и зависимых предприятий;

отчеты о прибылях и убытках по РПБУ;

аналитические расшифровки.

Аналитические расшифровки легче всего представить себе как аналог Excel-таблиц двух видов:

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

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

Таблицы с аналитическими расшифровками, как правило, содержат от 10 до 50 колонок - в зависимости от вида сделки. Количество видов таблиц зависит от состава применяемых в банке финансовых инструментов и методики подготовки отчетов по МСФО, принятой в банке. Как правило, количество видов аналитических расшифровок не превышает 60. Состав и вид таблиц уточняется в результате анализа методики подготовки отчетов, применяемой в конкретном банке.

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

Расшифровка 1. Капитал.

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

Расшифровка 1/2. Уставной капитал и эмиссионный доход. Таблица заполняется для подготовки отчета о движении капитала.

Расшифровка 2. Межбанк.

Расшифровка 2/1. Выданные межбанковские кредиты. Таблица составляется по лицевым счетам в разрезе банков-заемщиков с проверкой сумм по соответствующему балансовому счету.

Расшифровка 2/2. Остатки на текущих счетах в банках-корреспондентах (NOSTRO). Таблица составляется по лицевым счетам в разрезе каждого корреспондентского счета.

Расшифровка 2/3. Полученные межбанковские кредиты. Таблица, отражающая данные по всем кредитам, полученным от банков-кредиторов, которые не были погашены по состоянию на отчетную дату. Таблица составляется по лицевым счетам балансовых счетов второго порядка, в разрезе полученных кредитов/депозитов по состоянию на отчетную дату.

Расшифровка 2/4. Остатки на текущих счетах (LORO). Таблица составляется по лицевым счетам в разрезе каждого корреспондентского счета.

Расшифровка 3. Кредиты.

Расшифровка 3/1. Крупные кредиты, выданные банком. Таблица отражает данные по 20 крупнейшим заемщикам Банка на отчетную дату в разрезе заемщиков.

Расшифровка 3/2. Кредиты юридических лиц. Таблица, содержащая информацию об Овердрафтах, Кредитных линиях, Кредитах юридических лиц, Траншах кредитных линий, Траншах овердрафтов, Факторинговых сделках.

Расшифровка 3/3. Кредиты физических лиц. Таблица, содержащая информацию о Кредитах физическим лицам по их видам.

Расшифровка 3/4. Гарантии. Перечень гарантий, отраженных и неотраженных по внебалансовому счету.

Расшифровка 3/5. Невостребованные остатки кредитных организаций. Перечень кредитных линий, отраженных и неотраженных по внебалансовому счету.

Расшифровка 4. Аккредитивы выданные и полученные. Перечень аккредитивов, отраженных и неотраженных по внебалансовому счету.

Расшифровка 5. Векселя.

Расшифровка 5/1. Векселя, депозитные и сберегательные сертификаты, облигации, выпущенные банком. Таблица в разрезе балансовых счетов 2 порядка.

Расшифровка 5/2. Векселя в портфеле банка. Таблица, содержащая информацию о всех векселях выпущенных не самим банком (торговые, инвестиционные и т.д.) - в разрезе векселедателей и балансовых счетов второго порядка.

Расшифровка 6. Портфель гоcударственных долговых обязательств. Таблица отражает данные по портфелю ценных бумаг Банка, в разрезе их типов (ГКО, ОФЗ и т.д.), серий, выпусков и номиналов ( в разрезе балансовых счетов второго порядка).

Расшифровка 7. Договора аренды и лизинга, действующие в течение отчетного периода. Таблица в разрезе филиалов и балансовых счетов.

Расшифровка 8. Вложения в акции и долевое участие. Таблица в разрезе балансовых счетов 1 порядка.

Расшифровка 9. Срочные сделки. Таблица в разрезе финансовых инструментов (ценные бумаги, валюта, драг.металлы) и балансовых счетов.

Расшифровка 10. Срочные депозиты и счета юридических и физических лиц. Таблица в разрезе клиентов, валют и балансовых счетов.

Расшифровка 11. Нематериальные активы. Таблица, отражающая данные по нематериальным активам, созданным банком а также прочим нематериальным активам.

Расшифровка 12. Основные средства. Таблица в разрезе значений балансовых счетов второго порядка.

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

Расшифровка 14. Изменение резерва под возможные потери по ссудам. В таблице расшифровываются балансовые счета по учету резервов на возможные потери и символы отчета о прибылях и убытках.

Расшифровка 15. Операции со связанными сторонами. Таблица содержит финансовую информацию о взаимоотношениях банка с акционерами, владеющими более 5% акций Банка, руководством и родственниками руководства банка, инвестиции Банка более 10%, любыми другими организациями и частными лицами, которые прямо или косвенно могут повлиять на деятельность Банка, либо на деятельность которых влияет Банк.

Помимо исходных данных, необходимых для автоматизации отчетов по МСФО, требуется определить состав алгоритмов корректировок и расчетных процедур, применяемых при подготовке отчетности. В среднем по банкам их количество составляет:

Для подготовки Пробного баланса - 18 алгоритмов группировки статей и расчета 4 итогов.

Для подготовки Пробного отчета о прибылях и убытках - 17 алгоритмов группировки статей и расчета 4 итогов.

Для выполнения корректировок при подготовке баланса и отчета о прибылях и убытках - более 50 видов алгоритмов.

Для подготовки отчета о движении денежных средств - Разработачная таблица, содержащая алгоритмы 54 исходных корректировок, 46 производных корректировок и расчета 7 вспомогательных таблиц.

Для подготовки отчета об изменении собственных средств акционеров - более 20 видов алгоритмов.

Для подготовки Примечаний к консолидированной отчетности - алгоритмы расчета значений для 51 таблицы.

Как правило, нет необходимости в автоматизации абсолютно всех отчетов по МСФО и автоматизации всех процедур для ее подготовки. Службе автоматизации банка следует выявить "узкие места" в текущей технологии подготовки отчетов по МСФО и именно их подвергнуть автоматизации.

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

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

При этом необходимо сделать следующее:

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

Разработать регламент выверки и периодичность выпуска отчетов по МСФО, которые будут автоматизированы.

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

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

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

Определить состав и периодичность сбора в систему подготовки отчетов по МСФО лицевых счетов, проводок, клиентов, аналитических расшифровок.

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

Определить состав алгоритмов и выполнить их описание:

Для корректировок, которые будут автоматически рассчитываться на основании отчетности по РПБУ (баланс и отчет о прибылях и убытках).

Для корректировок, которые будут автоматически рассчитываться на основании аналитических расшифровок.

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

Для корректировок, которые будут выполняться вручную. Для этого вида корректировок описание алгоритма не требуется.

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

Выполнение перечисленных выше работ или хотя бы только их части позволит выработать аргументированное решение о наиболее эффективном способе автоматизации отечности по МСФО в конкретном банке.

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

Парадоксы автоматизации отчетности по МСФО

Еще на стадии выработки стратегии автоматизации отчетов по МСФО сотрудники банков могут придти к парадоксальным, на первый взгляд, выводам о целях выполнения проекта. Оказывается что, решая частную задачу подготовки отчетности по МСФО, закладывается солидная основа для решения иных, даже более актуальных задач по управлению банком.
Например, при организации процесса сбора аналитических расшифровок о кредитах, выданных в Головной конторе и филиалах банка оказывается, что на самом деле решается задача создания единого кредитного портфеля многофилиального банка. Собранная в Хранилище данных информация о кредитах может быть использована не только для подготовки корректировок для отчетности по МСФО, но и для оперативного анализа кредитного портфеля, анализа ликвидности и кредитного риска.
При сборе из филиалов информации о клиентах банка с целью подготовки корректировок по резервам в соответствии с принципами МСФО, создается единая база данных клиентов банка, позволяющая выполнять расчеты их доходности и снабжать ценной аналитической информацией менеджеров по работе с клиентами.
Сбор в Хранилище данных Главных книг бухгалтерского учета филиалов, дочерних банков и зависимых предприятий позволяет автоматизировать процессы первоначальной трансформации данных РПБУ в МСФО и выполнения ряда корректировок. Вместе с тем закладывается основа для решения задач контроллинга, мотивации филиалов, реализации управленческого учета.
В этих парадоксах находит подтверждение идея о том, что подготовка и автоматизация отчетности по МСФО может послужить катализатором для переосмысления и улучшения подходов в управлении банком и его автоматизации. Поэтому усилия и средства, вкладываемые в автоматизацию отчетности по МСФО могут быть с успехом компенсированы за счет улучшения бизнес-процессов по управлению банком и повышения качества интегрированной системы автоматизации банка.
Автор надеется, что эта статья, если и не дала четких методических рекомендаций IT-службам банка, то по крайней мере заложила основу для предметного обсуждения задач автоматизации отчетов по МСФО с бизнес-подразделениями и руководством банка.
document.write('');

Почему молчат разработчики программного обеспечения для банков?

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

Причина первая

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

Причина вторая


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

Выводы

Службам автоматизации банков, и тем более компаниям-разработчикам программного обеспечения, очень трудно объяснить своим заказчикам, почему полная автоматизация отчетов по МСФО для конкретного банка стоит не менее сотни тысяч долларов и занимает для своего воплощения более года кропотливого труда сотрудников поставщика системы и самого заказчика. И это в то время, когда 1-2 сотрудника многофилиального банка, вооруженные MS Excel, с успехом справляются с подготовкой отчетности по МСФО в течении 2-3 недель. Поэтому и молчат разработчики программного обеспечения для банков.

Предмет автоматизации отчетов по МСФО

Проблемы поставщиков ПО для банков не могут являться основанием для IT-службы банка, чтобы ничего не делать для решения поставленной перед ними задачи. Для того, чтобы решить эту задачу, следует сначала определить "размер разрушений", а именно - выявить главную особенность технологии подготовки отчетности по МСФО в своей организации. Она зависит от степени диверсификации бизнеса банка, размера его филиальной сети или количества дочерних предприятий. Не секрет, что даже очень маленький банк может являться частью достаточно большого холдинга, включающего в себя предприятия, ориентированные на развитие различного рода бизнесов. Также в России немало банков, стремящихся расширить свое присутствие и влияние в регионах посредством открытия филиалов и покупки дочерних банков. Для этих структур наиболее актуальной задачей является подготовка консолидированной отчетности по МСФО. Для унитарных банков или банков с небольшим количеством филиалов задача подготовки отчетности по МСФО является более простой. Поэтому дальнейшие рассуждения и рекомендации будут наиболее интересны многофилиальным банкам и финансово-промышленным группам.
Если банк входит в холдинг или имеет филиальную сеть, в том числе состоящую из дочерних банков, то он должен решать специфические задачи при подготовке отчетности по МСФО:

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

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

Сбор и выверка исходных данных бухгалтерского учета из подотчетных организаций в составе лицевых счетов и проводок.

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

Сбор и согласование справочной информации (клиенты, контрагенты, курсы валют и т.д.).

Первоначальная трансформация РПБУ в МСФО посредством выполнения алгоритмов группировки счетов и статей РПБУ в статьи МСФО с последующим выпуском пробных отчетов по МСФО до выполнения корректировок.

Выполнение корректировок, в автоматическом режиме или вручную, отражающих мотивированное суждение специалистов, с последующим выпуском отчетов по МСФО до консолидации.

Выполнение консолидации с выделением внутригрупповых оборотов, операций со связанными сторонами, определением доли меньшинства и выпуском Реестра межгрупповых операций.

Выпуск консолидированной отчетности по МСФО.

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

Сбор аналитических расшифровок.

Сбор данных бухгалтерского учета.

Автоматизация процесса выполнения корректировок.

Выполнение консолидации.

Сбор справочной информации.

Выпуск консолидированных отчетов.

Первоначальная трансформация РПБУ в МСФО.

Полученное таким образом знание позволит сотрудникам IT-служб банка наиболее эффективно построить стратегию автоматизации отчетов по МСФО в своем банке.

IT консалтинг - статьи

Анализ ошибок и исправлений в МИС

Подсистема	До применения middleware	После применения middleware
Количество ошибок в неделю	Время ис-правления ч/неделю	Количество ошибок в неделю	Время ис-правления ч/неделю
Микроядро системы	26	4,5	2,9	3,5
Статистика	8	6,2	1,3	0,8
Лабораторная подсистема	1,2	3,4	0,2	1,2
Внешние программы	13	14,2	2,5	6,5
Календари	3	4,4	0,4	1,2

Дополнительно с широким применением базовых библиотек класса middleware, выпол-ненных в виде динамически подсоединяемых библиотек (dynamic link libraries DLL), было предложено встроить во все основные функции единый обработчик ошибок. В случае фа-тального прекращения работы какой-то функции middleware он пересылал системе резуль-тат, переданный по умолчанию, и дополнительно отправлял максимально возможную ин-формацию разработчику по e-mail. Это позволило сократить время, необходимое на анализ и исправление ошибки в среднем на 45-55%. Нередко исправление ошибки производилось уже до того, как пользователь сообщал об этом программистам [10, 14].
Необходимо отметить, что применение модели программного обеспечения системы на основе использования общих сервисов middleware позволяет применять эволюционный ме-тод, называемый в литературе Spiral Model [12, 18]. При этом возможно внедрение новых версий информационной системы путем простого подмена базовых сервисов на новые вер-сии. Эти версии могут работать как со старой информационной системой, так и с новой, без необходимости повторного обучения персонала или исправлений в структуре существующей базы данных.
Таким образом, применение сервисов middleware позволило в среднем увеличить появ-ление новых версий программ с 4 до 7 в месяц (на 75%), снизив удельную стоимость каждой новой версии на 22%. Применение указанных технологий позволило разработать систему со значительной экономией. Так, разработка крупнейшей отечественной МИС "Интерин" длит-ся 9 лет, штат разработчиков насчитывает 25 человек. Разработка ИС, в которой принимают участие авторы, осуществляется 4 года и только 2 последних из них в ней постоянно участ-вует 2 программиста. Приняв, что данная МИС содержит только 50% от возможностей МИС "Интерин", зарплата одного программиста составляет около $300 (долл. США), а работа ве-дется 11 месяцев в году, получена экономия по сравнению с традиционными технологиями около $75900 в год. Таким образом, за 4 года работы стоимость разработки МИС на основе объектно-реляционного подхода составила 5,3% от суммы, которая потребовалась бы для создания МИС с применением традиционного подхода.
Рис. 2. Схема работы промежуточного программного обеспечения и его место в структуре программ медицинской информационной системы
На этапе, когда ИС становится пакетом многочисленных программ, остро встает вопрос их поддержки. Актуальность ее растет вместе со сроком эксплуатации и ростом количества пользователей. Наряду с начальными капитальными затратами, администрирование инфор-мационной системы составляет значительную цифру в смете расходов ЛПУ [3, 5, 10, 14]. Применение сложных комплексных информационных систем требует высококвалифициро-ванного штата программистов и администраторов [12, 15]. С ростом количества подключен-ных к базе данных системы пользователей растет и сложность ее обслуживания. В таблице 3 приведены средние еженедельные затраты времени работы администратора МИС, получен-ные в результате хронометрических исследований в медицинском центре.
Таблица 3

Использование однотипного программного кода в различных подсистемах МИС

Подсистема	Общий код	Уникальный код
% от всего	% времени на разработку	% от всего	% времени на разработку
Документы ИБ и АК	45	10	55	90
Лабораторная подсистема	74	38	26	62
Статистика	17	9	83	91

Как представлено в таблице 1, в некоторых видах ПО доля повторяющегося кода со-ставляет значительную часть. Исключение его из этапа разработки нового приложения по-зволило сократить среднее время создания новой программы с 3,8 до 2,9 недель (на 23,68%). Кроме этого, использование проверенных библиотек позволило значительно, на 35-50%, со-кратить количество последующих исправлений ошибок. Фактически вся основная работа над ошибками была связана с исправлением уникального кода приложения, в редком случае (в среднем 5-7 ошибок на 100 исправлений) исправлением используемых middleware-сервисов.
Таблица 2

Метод исправления справочников.

Применяется, если приложение само не изменило свою версию, однако его справочник устарел по сравнению с эталоном системы.
Если все проверки пройдены, исполняемый файл запускается.
Рис. 3. Алгоритм работы подсистемы установки и обновления программ
Применение данной технологии позволило сократить время, необходимое на обновле-ние клиентского программного обеспечения с 2-3 дней до 5-10 сек. (в среднем), снизить за-траты ЛПУ на администрирование информационной системы на 47,8% за счет снижения трудозатрат администратора системы и возможности совмещения ставок программиста и администратора. Ежегодная экономия составляет около $72 на одного пользователя.

Метод обновления.

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

Метод переустановки.

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

Об авторах

Гусев Александр Владимирович - старший инженер-программист вычислительно центра ОАО "Кондопога", аспирант кафедры прикладной математики и кибернетики ПетрГУ, г. Кондопога.
Дуданов Иван Петрович - член-корр. РАМН, д.м.н., профессор, зав. кафедрой госпи-тальной хирургии, директор Карельского научно-медицинского центра СЗО РАМН, г. Пет-розаводск.
Романов Федор Анатольевич - главный врач санатория-профилактория ОАО "Кондопо-га", аспирант кафедры госпитальной хирургии ПетрГУ, г. Кондопога.
Дмитриев Александр Геннадьевич - инженер-программист ОАО "Кондопога", г. Кон-допога.

Особенности в проектировании и практической разработке медицинской информационной системы

, член-корр. РАМН ДудановИ.П., Романов Ф.А., Дмитриев А.Г.
Карельский научно-медицинский центр СЗО РАМН, Петрозаводск
В последние годы в России появился целый ряд уникальных разработок в области комплексных медицинских информационных систем (МИС), предназначенных для автома-тизации работы учреждений здравоохранения. Одними из самых интересных являются: ин-формационная система "Интерин" (Институт программных систем РАН), МИС "Артемида", МИС "Амулет" и некоторые другие. Эти системы не только разработаны, но и активно раз-виваются - распространения и признания в практическом внедрении они получили за по-следние 2-3 года. В литературе опубликованы положительные отзывы коллективов клиник самого разного профиля и масштабов об опыте применения информационных систем в рабо-те [1, 3, 5, 10, 13, 14, 17-20]. Наметилась тенденция на комплексное решение разносторонних задач лечебного учреждения, что особенно радует и свидетельствует о качественном росте отечественных разработчиков в области медицинской информатики.
Однако при более глубоком изучении этого процесса все сильнее выделяется сущест-венная проблема: несмотря на наличие глубоко проработанных программных решений, практически отсутствует опыт полного перехода на электронный принцип хранения и обра-ботки информации в лечебном учреждении [8, 11]. Имеется ряд серьезных преград, через ко-торые не могут перешагнуть даже современно оснащенные клиники в своем стремлении от-казаться от бумажных носителей информации и повысить эффективность в организации сво-ей работы. Все они могут быть объединены в несколько групп.
Во-первых, существующая в России правовая база не обеспечивает должного уровня юридической защиты медицинских работников, применяющих информационные технологии в повседневной практике. Во-вторых, финансовые ресурсы большинства учреждений здра-воохранения пока не могут позволить им приобрести достаточное количество компьютерной техники и дорогостоящего программного обеспечения для комплексной автоматизации. По-этому этот процесс успешно протекает лишь в некоторых, зачастую далеких от медицинской направленности, разделах работы ЛПУ: статистика, бухгалтерия, автоматизация работы ад-министративного звена и т. д. В третьих, в России практически отсутствует школа, которая бы готовила профессионалов высокого уровня в области разработки и внедрения именно комплексных медицинских информационных систем, людей по определению работающих на стыке сложнейших наук - медицины и прикладной математики. Для становления отечест-венной школы в этой области творческим коллективам необходимо обмениваться наблюде-ниями и мнениями в разработке программных продуктов, накапливая тем самым специаль-ные знания и формируя потенциально выгодные направления в поиске эффективных реше-ний разработки и внедрения комплексных МИС.

Коллектив авторов имеет 5-летний опыт в разработке медицинской информационной системы. За это время изучена на практике эффективность различных подходов. Применя-лись Microsoft FoxPro разных версий, CA Clipper, Lotus Notes, начиная с версии 4.6, СУБД Microsoft SQL Server, Microsoft Access, Borland Paradox, MySQL и IBM DB2. Апробирован вариант написания программного обеспечения на Borland Delphi, сервлеты на Java, применя-лись Lotus Designer и мультиплатформенный Lotus Script и некоторые другие технологии. Серверная часть системы работала под управлением Microsoft Windows NT Server, Microsoft Windows 2000 Server и Red Hat Linux 6.0. В качестве клиентской операционной системы применялись все версии Windows, начиная с Microsoft Windows 95. Кроме инструментария, была проведена работа по изучению эффективности различных методик проектирования ба-зы данных МИС. В итоге мы остановились на применении принципа объектно-реляционной парадигмы в проектировании БД МИС [4]. Кратко концепция этого подхода выражается в том, что в силу особенностей предметной области необходимо разрабатывать информацион-ную систему на базе синтеза двух, различных по своей природе, систем управления базами данных (СУБД) - объектно-ориентированной и реляционной. Только на основе этого синтеза удается исключить недостатки обоих СУБД и использовать их достоинства. В качестве ос-новной СУБД используется Lotus Domino Server R6.0.3 для функционирования объектной части МИС и MySQL 4.0.17 для реляционной составляющей системы. Разработка программ-ного обеспечения ведется в среде Lotus Designer R6.0.2 и Borland Delphi 6 Professional SP3. В ходе изучения эффективных способов создания приложений для системы найдено несколько, на наш взгляд, интересных находок.

Во-первых, одной из самых существенных причин увеличения стоимости МИС мы считаем высокую стоимость самой разработки. Изучив причины этого явления, мы пришли к выводу, что не последнюю роль в этом сыграла традиция создания медицинских информа-ционных систем на основе так называемых АРМ-ов (автоматизированных рабочих мест). Причем зачастую под АРМ-ом понимается именно клиентское программное обеспечение, хотя изначально этот термин имел более широкое толкование [10]. Чаще всего разработка АРМ-ов ведется по следующей методике: разработчики выбирают некоторую общую задачу (например, создание электронной истории болезни для стационара), проектируют структуру базы данных, разрабатывают приложение для работы с ней. Нередко это приложение выпол-няется в виде нескольких версий - АРМ главного врача, АРМ регистратора, АРМ лаборанта и т. д. Разработка систем в 65% случаев ведется на Borland Delphi. При этом даже на выпуск очень сырой версии АРМа тратится 4-8 месяцев. Затем столько же времени уходит на обкат-ку. Вместе с тем, по нашим оценкам, разработчику приходится 10-20% времени тратить на создание специфичного для медицинской области кода. Остальная часть, причем самая тру-доемкая и ответственная, приходится на разработку механизмов, обеспечивающих целост-ность данных, подсистему безопасности и администрирования МИС, связь с периферийным медицинским оборудованием и т. д.


Однако, не вызывает сомнений, что эти решения значительно уступают промышлен-ным решениям для корпоративного рынка, над которыми трудятся лучшие специалисты и которые прошли многолетнюю проверку. В связи с этим вызывают недоумение подобные попытки "изобрести велосипед". На наш взгляд, разработка МИС не должна осуществляться созданием и дальнейшей интеграцией отдельных АРМов. Для создания МИС необходимо применять готовые программные платформы для групповой работы, уже имеющие в своем арсенале мощные средства для мультиплатформенной разработки программы, готовые тех-нологии для развертывания и управления подсистемой безопасности. В своей работе мы вы-брали пакет групповой работы Lotus Notes/Domino, разрабатываемый в настоящее время корпорацией IBM. Эта платформа является за рубежом стандартом "де факто" для создания мощных информационных систем, ориентированных на обработку электронных документов и мы считаем, что она наиболее подходит для создания медицинских информационных сис-тем.

Работа над созданием МИС "Кондопога" на основе Lotus Notes/Domino версии 4.6 на-чата в сентябре 1999 года. Через 2 месяца МИС, включающая подсистемы работы врача, клинической и биохимической лаборатории, функциональной и рентгенологической диагно-стики, аптеки и планирования рабочего времени была поставлена в эксплуатацию. А еще че-рез 2 месяца лечебное учреждение, использующее систему, полностью перешло на элек-тронный способ хранения информации, отказавшись от бумажных носителей.

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


Однако количество таких БД в МИС является вариабельным и зависит от количества функциональных групп пользователей, имеющихся в ЛПУ. Так, в стационаре это может быть выделенная БД для каждого отделения или корпуса. Для поликлиники - это могут быть БД, разделенные по участкам обслуживания. Кроме того, в этих БД специальным образом хра-нится только актуальная информация, а неиспользуемые данные помещаются в БД архива. Для решения ряда задач может быть принята либо связанная с объектно-ориентированным ядром реляционная БД, либо специальным образом сконструированные представления, ко-торые мы называем регистрами (рис. 1).

Рис. 1. Укрупненная схема объектно-реляционной базы данных медицинской информационной системы

Проектирование структуры БД, таким образом, позволяет достичь стабильно малого объема БД МИС в течение практически всего срока ее эксплуатации, а тем самым обеспе-чить максимально возможную производительность работы МИС. Так, начиная с 1999 года база данных историй болезни пациентов, проходящих реабилитацию в медицинском центре, имеет объем 26-29 Мбайт. При этом вся информация за время работы центра сохранена, а скорость работы остается стабильно высокой. Сложностью указанной методики является то, что программное обеспечение информационной системы должно поддерживать любое коли-чество физических баз данных в ядре системы, объединенных в одну логическую структуру.

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

определить, какое количество физических баз данных и их имен соответственно установ-лено на сервере;

определить возможность доступа к каждой базе данных в отдельности;


выполнить соответствующий запрос к каждой базе данных, указав в правильном формате полный адрес, включающий имя сервера и имя базы данных на нем;

обработать и запомнить полученный ответ;

повторить шаги 2-4 для каждой базы данных;

сложить накопленные ответы и обработать их, как единый пакет информации.

Доказано [5, 10, 16, 17, 19, 20, 22], что для эффективного решения такой задачи необхо-димо исключить в текстах программ МИС прямое обращение к базам данных. Взамен этого предложено использовать специальное промежуточное программное обеспечение, называе-мое сервисами middleware. Схема работы МИС на базе сервисов middleware показана на ри-сунке 2. С целью определения эффективности разработки системы с применением объектно-ориентированной технологии на основании использования сервисов middleware, авторами был выполнен анализ работы по созданию информационной системы в период 1999-2001 гг. Были получены следующие данные (таблица 1).

Таблица 1

Список использованной литературы

Айламазян А. К., Гулиев Я. И. Данные, документы и архитектура медицинских инфор-мационных систем.

Айламазян А. К., Гулиев Я. И., Матвеев Г. Н., Турна И. А., Белова И. А. ИС КОТЕМ-2001: Требования, проблемы, решения.

Андерсон К., Минаси М. Локальные сети. Полное руководство: Пер. с англ. - К.: ВЕК+, ЭНТРОП, Спб.: КОРОНА принт, 1999. - 624 с.

Андреев А. М., Березкин Д. В., Кантонистов Ю. А. Выбор СУБД для построения инфор-мационных систем корпоративного уровня на основе объектной парадигмы // СУБД 1998. - № 4-5. - С.26-50.

Губин И. М., Тарасов В. В., Антонов Р. А. и другие. Разработка и внедрение новой авто-матизированной информационной системы ЦКБ // Кремлевская медицина. Клинический вестник, 2000. - №4. - С.51-54.

Гусев А. В., Романов Ф. А., Дуданов И. П.. Опыт разработки медицинской информаци-онной системы // Медицинский академический журнал, 2001.- №1.- Приложение 1.- С.18.

Гусев А. В., Романов Ф. А., Осиик Т. А.. Применение медицинской информационной системы в работе клинических лабораторий медицинского центра // Медицинский ака-демический журнал, 2001. - № 1. - Приложение 1. - С.19.

Гусев А. В., Дуданов И. П. Оценка 3-летнего опыта разработки и внедрения информаци-онной системы: выводы и перспективы // Медицинский академический журнал, 2002. - Том 2. - Приложение 2. - С.56-57.

Гусев А. В., Дуданов И. П., Романов Ф. А. Информационная система в медицине - кон-цептуальная модель.

Гусев А. В., Романов Ф. А., Дуданов И. П., Воронин А. В., Информационные системы в здравоохранении. ПетрГУ. Петрозаводск, 2002. - 120 с.

Дуданов И. П., Гусев А. В., Романов Ф. А., Воронин А. В. и соавт.. Информационная система в здравоохранении - концептуальная модель // Сердечно-сосудистые заболева-ния. Бюллетень НЦССХ им. А. Н. Бакулева РАМН. Том 3. - № 11. - 2002. - С.332.

Дуданов И. П., Гусев А. В., Романов Ф. А., Воронин А. В. Информационные системы в здравоохранении // Медицинский академический журнал, 2002. - № 1.- Том 2.- Стр.58-77.

Дуданов И. П., Гусев А. В., Романов Ф. А., Кемпи С. И. Региональная информационная система "Кондопога" // Сердечно-сосудистые заболевания. Бюллетень НЦССХ им. А. Н. Бакулева РАМН. 2002. - Том 3. - № 11. - С.335.

Дуданов И. П., Гусев А. В., Романов Ф. А., Кемпи С. И. и соавт. Создание "паспорта здо-ровья" больных с сердечно-сосудистыми заболеваниями с использования информацион-ной системы // Медицинский академический журнал, 2003. - Том 3. - № 3. - С.125-133.

Ильмаст А. В., Марусенко К. М., Моисеев Е. В. Некоторые вопросы технологии разра-ботки МИС // Медицинский академический журнал, 2002. - Том 2. - Приложение 2. - С.85-86.

Принципы проектирования и разработки программного обеспечения. Учебный курс MCSD: Пер. с англ. - М.: Издательско-торговый дом "Русская редакция", 2000. - 608 с.

Шеррер Жан-Рауль. Информационные системы в здравоохранении: технология и орга-низация // Кремлевская медицина. Клинический вестник, 2000. - № 4. - С.15-17.

Claudio G. A. da-Costa, MD, Rodrigo P. Quaresma, BE and Renato M. E. Sabbatini, PhD. A Software Engineering Approach to the Development of Computer-Based Patient Record Sys-tems.

Ramamoorthy C. V., Prakash A., Tsai W. T., Usuda Y. Software Engineering: problems and perspectives. Computer. Outubro. 1984. - P.191-209.

Reidsema C., Szczerbicki E. A Blackboard database model of the design planning process in concurrent engineering. Cybernetics and Systems: An International Journal, 2001. - 32. - Р.755-774.

Sherrer J. R., Lovis C., Baund R., Borst F., Spahni S. Integrated Computerised Patient Records: The DIOGEN2 Distributed Architecture Paradigm with Special Emphasis on its Middleware Design. In User Acceptance of health Telematics Applications (I Iakovidis et al., Eds) IOS Press, Technology and Informatics 56. - P.15-31.

Spahni S., Sherrer Jr. Sauquet D., Sottile PA. Consensual trends of optimizing the constitution of middleware. ACM SIGCOMM Computer Communication. - 1998. - V.28, №5. - P.76-90.

Трудозатраты администратора МИС

№	Вид деятельности	% общего времени	Примечание
1	Обслуживание вызовов пользователей на местах	38
2	Установка пакетов исправлений	17
3	Отправка сообщений об ошибках разработчикам системы	7.8
4	Плановое обслуживание клиентских ПК (дефраг-ментация диска, проверка на вирусы)	6,9
5	Знакомство с литературой	5
6	Анализ журналов безопасности	4
7	Установка новых приложений	3,5..45,7	45,7% при вне-дрении системы
8	Контроль за новыми версиями ПО и публикация-ми исправлений	3,2
9	Исправление сбоев в клиентских операционных системах	0,1-2,1	Максимум при Windows 95/98
10	Внесение исправлений в системные справочники, текущие изменения настроек приложений	0,3-8,6	Максимум - при внедрении
11	Прочие	14,2

Использование встроенных в middleware-приложений глобальных обработчиков оши-бок позволяет сократить время по п. 3 (отправка отчетов об ошибках) практически до нуля, т. к. вся ключевые отчеты система формирует и отправляет автоматически. Обслуживание вызовов пользователей, исправление локальных сбоев на компьютерах пользователей и вне-сение исправлений в справочники системы являются практически неуправляемыми факто-рами. Плановое обслуживание компьютеров, анализ журналов работы системы, чтение спе-циальной литературы являются постоянными величинами, истекающими из функциональ-ных обязанностей администратора системы.
Следовательно, управляемыми факторами, способными сократить (перераспределить) трудозатраты технического персонала на обслуживание системы являются: установка при-ложений системы, установка исправлений (в т. ч. самой ИС и общесистемного ПО), контроль за новыми версиями ПО. Причиной высоких показателей в этих категориях является тради-ционный способ установки прикладного ПО: администратор сети запускает инсталляцион-ные пакеты на компьютерах пользователей, а затем по мере появления и т. н. "заплатки" к ним. Учитывая высокие показатели в выходе новых версий отдельных программ МИС на ба-зе ООП, 1 администратор может обслуживать до 22-25 пользователей. По нашему опыту, время от появления пакета исправлений до его полной инсталляции на всех компьютерах се-ти может составлять от 2-3 суток при работе 50 станций до 4-7 суток при работе 100-150 станций. Этот факт чреват тем, что злоумышленник может воспользоваться этим промежут-ком для нарушения системы безопасности или другого нанесения вреда, если он знает меха-низм ошибки, которую планируется исправить "заплаткой".

Анализируя эти проблемы, было предложено использовать технологию установки и об-новления приложений [8, 11, 14]. Суть ее работы состоит в следующем: в системе имеется выделенная база данных дистрибутивов приложений. Все команды на запуск приложений используют в своей работе специальный сервис, предоставляемый системой. Ей передается команда на запуск приложения, содержащая код программы и параметры ее запуска. Всю необходимую работу выполняет система, используя следующий алгоритм (рис. 3).

Определяется, имеется ли описание программного продукта с переданным кодом в цен-тре программ. Если описание не найдено, выдается сообщение об ошибке.

Вычисляются из описания программы необходимые данные, в частности: номер версии ПО, имя исполняемого файла и т. д.

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

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

IT консалтинг - статьи

ENOVIA

Но мало сделать информацию доступной, проект нужно еще создать и утвердить. Для этого IBM предлагает пакет ENOVIA, в который входят средства для совместной работы и приложения, реализующие трехмерную визуализацию, доступную за пределами CAD-системы, а также собственная CAD-система IBM, CATIA V5.11 (хотя IBM называет ее "Катия", кажется, инженеры скорее привыкнут к новшеству, если назвать программу "Катя").
К преимуществам использования ENOVIA и SMARTEAM стоит отнести возможность публикации информации о продукте на веб-сайте в реальном времени. То есть заказчику не обязательно посылать запрос, чтобы получить интересующую информацию. Достаточно зайти на сайт и воспользоваться возможностями портала. Кстати говоря, IBM уже давно пропагандирует использование порталов как средств внутреннего и внешнего взаимодействия и ведения бизнес-процессов. И это вполне естественно - если есть Интернет, почему не использовать его для того, чтобы получить дополнительный доход?
Но вернемся к возможностям ENOVIA. Конечно, не трудно использовать и другую CAD-систему, собственно, для того и создан SMARTEAM, чтобы работать с различными средами. Однако ENOVIA представляет собой законченный продукт, имеющий достаточно удобные модули. Вряд ли стоит перечислять их все - в любом случае, если это предложение привлечет ваше внимание, вы всегда найдете необходимую информацию на сайте ibm.com/solutions/plm. Но о наиболее интересных возможностях CATIA, пожалуй, нужно сказать несколько слов.
Самое приятное, что ENOVIA использует контекстное проектирование. Например, если инженер Петров передумал и решил сделать головку болта не шестиугольной, а восьмиугольной, то в проектах всех продуктов, использующих "болт Петрова", шестиугольные болты станут восьмиугольными. А это значит, что даже если никто не заметит такой невинной "шалости" и Петров не получит вовремя "по шее", по крайней мере, не возникнет проблем, когда вместо ожидаемых шестиугольных болтов вам привезут тонну восьмиугольных.

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

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

Также стоит отметить, что ENOVIA обладает возможностями графического портала. То есть увас появляется доступ к разработке через стандартный интерфейс браузера - нужно только загрузить привычный Internet Explorer и пройти авторизацию на сайте. Кстати, в рамках среды можно реализовать даже интерактивную работу с порталом, потому что ENOVIA обладает средой разработки приложений Java, которые, как известно, действуют независимо от используемой оболочки.

К интересным модулям ENOVIA отностится и система рендеринга в реальном времени. Используя документацию BOM (Bill Of Materials - описание материалов), вы можете получить готовую картинку и опубликовать ее в рамках того же портала.

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

Ну и что?

Возможно, вы скажете: "Ну, да, куча картинок, можно вставить в объект человека, можно заставить работать все это вместе - и что дальше?" А дальше, как раз начинается ваша работа. Ведь когда люди сталкиваются с абстракцией, им далеко не всегда удается выразить свое отношение однозначно, - для этого нужно иметь особый склад ума. В большинстве случаев, человек ориентируется на картинку, (а она у вас теперь есть), причем отражающую продукт именно таким, какой он получится. Разве это не дополнительный штык в вашем арсенале?
А что касается совместной работы - нет ничего проще. На самом деле вся выгода в том, что вы можете получить картинку в любой стадии разработки плюс создать итоговую модель гораздо раньше, нежели при традиционном подходе. Также вы сэкономите время на компоновке работ из разных CAD, ERP и прочих систем, поскольку SMARTEAM сделает все самостоятельно. А время, это, как известно - деньги. Вы выводите продукт раньше конкурентов, вы делаете его лучше, растет прибыль, и на вашем лице расплывается довольная улыбка. Что еще надо деловому человеку?

PLM: Take the Lead!

Прежде чем приступить к описанию возможностей конкретной системы, честно и откровенно признаюсь, данная статья посвящена решению IBM, а именно продуктам SMARTEAM и ENOVIA. Я не хочу сказать, что невозможно сделать это по-другому, однако решение IBM удобно своей законченностью, поскольку компания предлагает весь спектр услуг для бизнеса, начиная с вычислительных ресурсов "по требованию" и заканчивая полным пакетом программного обеспечения.
В рамках форума жизненного цикла обслуживания, проходившего под девизом "PLM: Take The Lead", обсуждались два программных продукта, составляющих полноценную инфраструктуру для работы с проектами.

SMARTEAM

Итак, давайте разберемся, что имеется в виду под производственной консолидацией:

доступность конструкторской документации

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

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

интеграция с различными ERP и прочими системами

Вот так выглядит упрощенный перечень требований, предъявляемых к программной среде, которую хочет видеть заказчик. SMARTEAM и представляет собой этакого спрута, который может работать совместно с различными системами, обеспечивая всех сотрудников необходимой информацией.
Обратите внимание, речь идет не о простой компьютеризации чертежей и переход на системы CAD (Computer aided Design - компьютерное проектирование). SMARTEAM позволяет работать с готовой документацией не зависимо от того, чем вы занимаетесь и каким программным обеспечением пользуетесь. В частности, вы можете обращаться к CAD-проектам прямо из окружения Microsoft Office.
Какую реальную выгоду способна принести предприятию единая база данных, доступная всем сотрудникам (естественно, если они обладают правами доступа)? Во-первых, над одним и тем же изделием могут работать несколько специалистов. То есть еще до выпуска продукта, технолог, при необходимости, оставит ремарку о невозможности создания такой детали и ошибка будет исправлена на ранней стадии проектирования. Во-вторых, отдел продаж может получить нужные сведения еще до завершения проекта и начать планирование его реализации. Также нельзя забывать, что через неделю работы вы продемонстрируете заказчику трехмерные наброски и базовые характеристики разработки. И если он скажет "нет" или выразит какие-нибудь пожелания, незамедлительно внести коррективы, оставив замечание прямо в базе данных.
Конечно, для каждого конкретного проекта SMARTEAM способен принести пользу. Однако два базовых принципа, которые вы напишете на стене своего офиса, начав пользоваться SMARTEAM, - это командная работа и доступность информации.

Валенки, валенки, не подшиты, стареньки...

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

Как ни странно, такое джентльменское отношение действительно повышает эффективность производственной и экономической деятельности. Кстати, в мире логических схем все обстоит точно так же. Согласно исследованиям американских ученых, если изменить принцип работы роутеров (устройств, которые выбирают, как вы получите веб-страницу - через Лондон или через Нью-Йорк) так, чтобы они учитывали последующую загруженность канала, помимо его остаточной пропускной способности на момент обращения к ресурсу, то скорость Интернета возросла бы в 1,33 раза только потому, что пропали бы "пробки", возникающие из-за резкой загрузки каналов. Когда проводилось данное исследование, за основу правил роутинга был взят принцип Джона Нэша, о котором снят фильм "Игры Разума". Вряд ли все было именно так, как в фильме, но сегодня действительно существует принцип экономики, изобретенный Джоном Нэшем, ставший чуть ли не краеугольным камнем всего сегодняшнего рынка. Как показывает практика, такой же метод срабатывает в электронных устройствах, и, быть может, он поспособствует развитию вашего бизнеса.

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

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

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

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

Жизненный цикл обслуживания продуктов: самолету тоже нужна нянька

«IT Manager », #5/2003
Вы никогда не задумывались, какой вопрос чаще всего задают себе люди, пытающиеся найти свое место в "прогнившей" системе капитализма? Я более чем уверен, что не только задумывались, но и сами не раз спрашивали себя: "Как заработать больше денег?"
Если я скажу, что знаю ответ на этот вопрос, вы либо решите, что я - Бог, либо выбросите IT Manager и больше никогда не возьмете его в руки. Оба исхода не принесут никакой пользы, поэтому не будем гадать на кофейной гуще, а попробуем научиться строить IT-инфраструктуру так, чтобы взять от системы все:

IT консалтинг - статьи

Качественный скачок

Появление трехмерного моделирования оказалось настоящим прорывом, вначале доступным только пользователям мощных графических Unix-станций. По-настоящему массовым 3D-моделирование стало ближе к середине 1990-х годов, когда 3D-CAD-системы были переведены на платформу PC. Какие же выгоды предоставило пространственное конструирование?
Первое преимущество мы уже назвали: конструкторам не приходится "переводить свои мысли" из пространственного в плоский вид. Качественно изменился процесс проектирования: теперь разработчик сразу видит свою конструкцию такой, какой она и будет в действительности.
Помогает объемная модель и в реализации массы сопутствующих функций. 3D-модель можно использовать для решения расчетных задач (анализ напряжений, перемещений, колебаний, гидродинамики, теплопередачи), подготовки управляющих программ для станков с ЧПУ, а также реалистичных изображений для технической документации и рекламных материалов, создания физических образцов на установках быстрого прототипирования. Ну и конечно, по 3D-модели создаются чертежи - причем делать это существенно проще, чем вручную, поскольку вся геометрия на чертеже формируется автоматически, позволяя конструктору не задумываться о правильности построения видов, разрезов и сечений.
Вслед за CAD-системами практически все CAM/CAE-пакеты стали трехмерными, позволив в некоторых случаях отказаться от чертежа вообще. Скорее всего, на подходе и технологические САПР, работающие напрямую с конструкторской 3D-моделью.
Если суммировать все вышесказанное, то не трудно определить важнейшее преимущество трехмерного моделирования: теперь ошибки можно найти и исправить на ранней стадии проектирования, до появления первых опытных образцов. А коррекция проекта на цифровой стадии несоизмеримо дешевле, чем обнаружение недочетов после изготовления дорогостоящей опытной партии. Еще пятнадцать лет назад аналитическая компания Gartner Group произвела оценку стоимости исправления одной-единственной ошибки на различных стадиях подготовки производства:

$1 Концептуальное проектирование

$10 Конструкторская проработка изделия

$100 Изготовление макета изделия

$1 000 Проектирование технологической оснастки

$10 000 Изготовление оснастки

$100 000 Выпуск установочной серии

$1 000 000 Серийное производство

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

Впрочем, было бы неверно говорить, что 3D-системы достигли вершины своего развития и проблем в этом направлении нет. Они существуют. Так, моделирование больших сборок, состоящих из десятков и сотен тысяч деталей, все еще является сложным для многих CAD-систем, эргономика работы конструктора пока далека от идеала. К тому же чем мощнее система, тем она труднее в освоении и работе. Короче, резервы для совершенствования есть, и немалые.

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

Итак, автоматизировав с помощью комплекса CAD/CAM/CAE/CAPP все направления подготовки производства, предприятие получает в свои руки цифровую модель изделия - это более высокий уровень, чем просто использование 3D-CAD-системы. Цифровая модель содержит как геометрию изделия, так и все необходимые расчетные данные, карты технологических процессов, ведомости, управляющие программы для станков, электронные описания изделия и технические руководства. Все прекрасно? Увы, огромный массив цифровой информации не только приносит пользу, но и доставляет значительные хлопоты создавшему его предприятию.

Новые задачи - новые решения

Простая автоматизация рабочих мест перестала устраивать предприятия. Почему? Время - вот важнейший фактор деятельности промышленного предприятия. В условиях усиливающейся конкуренции руководству предприятия необходимо решать вопросы роста и оперативного изменения номенклатуры выпускаемых изделий. Экономический эффект от "лоскутной" автоматизации минимален - ведь процесс проектирования остается последовательным, как во времена чертежных досок: конструкторы создают документацию, передают ее технологам, забирают обратно на корректировку, возвращают исправленную документацию технологам, те подготавливают технологическую документацию, согласовывают со снабженцами и экономистами и так далее. В результате ни полной экономической отдачи, ни действительно значимого сокращения срока подготовки производства автоматизация не приносит, хотя положительный эффект и достигается.
Не стоит забывать, что разработка и подготовка производства сложной, высокотехнологичной продукции - групповой процесс, в который вовлечены десятки и сотни специалистов предприятия или даже группы предприятий. В процессе разработки изделия возникает ряд проблем, влияющих на общий успех. Это в первую очередь отсутствие возможности видеть ключевые ресурсы, вовлеченные в процесс разработки, в их фактическом состоянии на данный момент времени, это организация совместной работы коллектива специалистов с привлечением компаний, поставляющих какие-либо компоненты для разрабатываемого изделия. Существенно сократить сроки подготовки производства можно только одним способом - за счет параллельного выполнения работ и тесного взаимодействия всех участников процесса. Эту задачу можно решить за счет создания единого информационного пространства (ЕИП) предприятия, другими словами, единого пространства цифровых данных о корпоративной продукции.
И здесь на сцену выходит новый класс систем, нацеленных на решение задач организации и координации работ инженерного персонала, - систем управления данными об изделии, PDM (Product Data Management). Конструкторы, технологи и другие специалисты не только получают информацию об изделии, но и дополняют ее, формируя состав изделия, который будет актуальным для разных служб предприятия. В дальнейшем, после изготовления изделия, информация о нем будет использована сервисными подразделениями для планового обслуживания, заказчиком - для конфигурирования готовой продукции под свои специфические потребности, а инженерным составом - для модернизации и изготовления нового изделия на основе уже спроектированного.
Еще в 1980-х годах поставщики САПР начали решать проблему хранения цифровой документации - так появились первые системы электронного архива. Архивирование и сейчас остается одной из функций PDM-систем. Однако современные PDM решают гораздо более широкий круг задач, позволяя полноценно реализовать следующую ступень развития САПР-технологий, аккумулировать цифровую информацию об изделии и непрерывно управлять (это ключевое слово) данной информацией на протяжении всего жизненного цикла изделия (ЖЦИ). Мы назвали концепцию PLM (Product Lifecycle Management) - принципиальным моментом современного этапа автоматизации промышленного производства.
А что представляет собой жизненный цикл изделия? Его основные этапы таковы:

Маркетинговые исследования потребностей рынка.

Научно-исследовательские и опытно-конструкторские работы (НИОКР).

Подготовка производства изделия на заводе-изготовителе серийной продукции.

Собственно производство и сбыт.

Эксплуатация и обслуживание изделий.

Утилизация изделий.

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



"Финансовый профиль" проекта создания, освоения и производства нового изделия

Сокращение сроков НИОКР и подготовки производства не только увеличивает прибыль компании за счет реализации дополнительной продукции, но и высвобождает средства для разработки новых продуктов, повышая общий доход предприятия. Реализация концепции PLM позволяет реально сократить непроизводственные стадии ЖЦИ. За счет чего это достигается? Рассмотрим подробнее функционирование основного ядра любого PLM-комплекса, системы PDM.

PDM-система крупным планом

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

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

Создание ЕИП для всех участников жизненного цикла изделия.

Автоматизация управления конфигурацией изделия.

Построение системы качества продукции согласно международным стандартам качества серии ISO 9000.

PDM-система управляет всеми связанными с изделием информационными процессами (в первую очередь, проектированием изделия и технологией его производства), а также всей информацией об изделии - его составом и структурой, геометрическими данными, чертежами, планами проектирования и производства, нормативными документами, программами для станков с ЧПУ, результатами анализа, корреспонденцией, данными о партиях и отдельных экземплярах изделия и многим другим.
PDM-система выступает в качестве средства интеграции множества используемых на предприятии прикладных автоматизированных систем (CAD/CAM/CAE/CAPP/ERP/MRP) за счет сбора поступающей из них информации в логически единую модель на основе стандартных интерфейсов взаимодействия.
Пользователями PDM-системы могут быть все сотрудники всех предприятий-участников жизненного цикла изделия: конструкторы, технологи, работники технического архива, а также сотрудники, работающие в других предметных областях (сбыт, маркетинг, снабжение, финансы, сервис, эксплуатация и т. п.). Главная задача PDM-системы - предоставить соответствующему сотруднику необходимую информацию в нужное время и в удобной форме (в соответствии с правами доступа).

Схема функционирования PDM-системы в едином информационном пространстве
Функционал PDM-системы можно четко разделить на несколько групп.

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

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

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

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

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

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

Подводим итоги

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

С чего начинался САПР

Создание сложного изделия немыслимо без его графического представления - рисунка, схемы, чертежа, однако на протяжении веков не существовало системного подхода к этим иллюстрациям, и в чертежах Леонардо да Винчи разобраться кому-то другому было весьма проблематично. Бурное развитие промышленности в XIX-XX веках потребовало от чертежа универсальности - чертеж, выполненный одним инженером, должен понять любой другой специалист, имеющий соответствующее образование. В итоге появились стандарты на оформление, а конструктора получили кульман - удобный инструмент для выполнения чертежей.
Но со временем ручное черчение перестало устраивать. Чем? Скоростью! Постоянно увеличивались объемы работ, а главное - росло количество типовых разработок на основе существующих изделий, ужесточились требования к срокам выпуска изделия. И тут как нельзя кстати начала интенсивно развиваться компьютерная отрасль: появление доступных и не слишком сложных в освоении (по сравнению с тем, что было раньше) компьютеров дали старт конструкторским системам CAD (Computer-Aided Design). Сначала такие системы представляли собой электронные кульманы - все, что прежде делалось карандашом и линейкой, было заменено соответствующими электронными командами, но не более того. Однако даже такая автоматизация приносила плоды: по мере накопления базы электронных чертежей все легче становилось проектировать новые и модифицированные изделия.
Двумерное проектирование активно развивалось до середины 1990-х годов. Системы обзавелись несметным количеством приложений, библиотек, надстроек, позволивших максимально автоматизировать и упростить большинство чертежных задач. Появились и развились в отдельные направления расчетные системы CAE (Computer-Aided Engineering), системы проектирования обработки изделий на станках с числовым программным управлением CAM (Computer-Aided Manufacturing) и многие другие специализированные приложения, основанные на работе с данными, предоставляемыми CAD-системами. Параллельно развивался класс систем технологической подготовки производства САПР ТП (Computer-Aided Process Planning, CAPP), предназначенных для формирования технологических данных об изделии, ведения централизованного архива этой информации и автоматизированного выпуска технологической документации.
Однако плоское проектирование все-таки неестественно для человека - ведь мы мыслим в трехмерном пространстве, живем в окружении трехмерных объектов. И развитие вычислительных систем позволило вывести технологии проектирования на новый уровень.

"Лестница" развития систем промышленной автоматизации

Тема САПР и промышленной автоматизации

Чем характерен бизнес в производственной сфере? Давайте посмотрим на диаграмму временных и материальных издержек промышленного предприятия. Не менее 70% затрат приходится на производственные функции, и именно в сфере производственной деятельности могут быть скрыты основные резервы, способствующие сокращению сроков выпуска новой продукции и повышению конкурентоспособности предприятия. А что такое производство? Обычно 5-10% времени, которое отводится для самого процесса, занимает непосредственно выпуск изделия, а все остальное - подготовительные работы.

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

Внедрение: готовность к изменениям

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

Этапы внедрения PDM-системы
Перед проектной группой ставится целый комплекс задач: установка системы, организация работы и настройка серверов, настройка и наполнение баз данных и их адаптация к требованиям предприятия, организация автоматизированного обмена заданиями между сотрудниками и подразделениями. Как видно, объем работ значительный - внедренческий проект PDM-системы по трудоемкости не уступает внедрению системы управления корпоративного уровня.

IT консалтинг - статьи

"Проект внедрения...."

Именно такими словами, озаглавлено сотни проектов, которыми занимаются интеграторы. Впрочем, само понятие "проект" разобрать не помешает. Как правило, под термином "проект" подразумевается ограниченный во времени организационный стратегический план для создания уникального продукта или услуги, который может выполняться как одним человеком, так и коллективом. Данное определение проекта ничего не говорит о длительности выполнения работ - оно может варьироваться в самых широких пределах. Неизменным остается лишь конечная цель проекта - получение прибыли или некоего стратегического результата, а также инструмент оптимизации хода выполнения работ - Project Management. Последний подразумевает использование определенных знаний, умений, средств и методов для достижения поставленных целей.
Приведенное определение, позаимствованное из руководства по основам управления проектами (A Guide to the Project Management Body of Knowledge), созданного Project Management Institute, к сожалению, не отражает тех трудностей, с которыми приходится сталкиваться большинству компаний при реализации даже относительно несложных проектов. На наш взгляд, все они связаны с отсутствием у исполнителей современных знаний в области оптимального ведения проекта, а также неумения создать или организовать по-настоящему действенную функциональную команду. И если первая проблема решается достаточно просто - обучением имеющегося персонала или наймом квалифицированного, то решение второй куда сложнее. Дело в том, что принцип формирования команды, принятый в нашем обществе, не правилен и преодоление стереотипов, связанных с ним, вызывает непонимание у руководства большинства компаний. Иногда дело доходит до саботажа в рядах менеджеров верхнего уровня (не являющихся владельцами компании). Не стоит забывать и об особенностях национального менталитета. К слову, они почему-то полностью нивелируют преимущества использования средств ускоренной разработки программных продуктов, зарекомендовавших себя с наилучшей стороны в западных компаниях.
Только очень маленький проект может вести один человек. Фактически проведение проекта однозначно требует организации групповой работы. Из чего следует, что необходимо обладать знаниями по формированию рабочих групп - знать, какие роли нужны для работы группы, уметь подбирать людей на эти роли. Для этого могут быть использованы различные методики формирования команд, для ускорения начальных стадий формирования групп, усиления мотивации работников. Эти техники произошли из области групповой психотерапии, игровой терапии, НЛП. В общем, организация групповой работы требует знаний и навыков из области управления и психологии, а также наличия лидерских качеств у руководителей.
Одна из важнейших задач любого руководителя проекта или организации заключается в том, чтобы пробудить у своих подчиненных неподдельную заинтересованность к работе. В тоже время высшим пилотажем управленческой деятельности можно по праву считать способность менеджера раскрыть весь трудовой потенциал своего сотрудника, получить максимальный эффект от его пребывания в коллективе, а также взрастить полноценного лидера того или иного направления действия компании. Почти все корифеи современной школы бизнеса признают так или иначе, что работа с кадрами имеет гораздо большее значение, чем, например, стратегическое планирование или выстраивание процедур управления производственными процессами. И с этим достаточно трудно поспорить, ведь, собственно, кадрам в итоге и придется заниматься не только разработкой бизнес-схем и стратегий, но и их воплощением в жизнь. Поэтому представляется весьма важным создать собственную корпоративную схему организации работы с персоналом.
В общем случае управленческую работу можно поделить на три составляющих. Важнейшая из них - произведение менеджером точной оценки индивидуальных особенностей своих подчиненных. Не секрет, что у любого менеджера в ходе работы появляется собственный опытный механизм выявления и подготовки лидеров подшефного ему коллектива по тем или иным направлениям его деятельности. Кроме того, в организации формируется так называемый конвейер подготовки лидеров и ведущих специалистов (не путать с карьерной лестницей, направленной, правда, параллельно конвейеру подготовки), который является важнейшей составляющей мотивации сотрудников и базой для реализации долгосрочных планов и стратегий.
Впрочем, именно конвейер подготовки лидеров из числа сотрудников персонала в большинстве случаев является наиболее слабым местом, так как ситуации, в которых на ключевые посты назначают людей, не удовлетворяющих предъявляемым к ним требованиям, имеют место сплошь и рядом. Многие управляющие (заметим, именно управляющие или владельцы компаний, а не профессиональные менеджеры) считают, что на место лидера команды должен быть поставлен человек, прекрасно исполняющий свои обязанности или приносящий большую часть дохода компании, поскольку в свое время сам управляющий был продвинут по соответствующей служебной лестнице, став на определенном этапе лидером. Понятно, что данный подход не верен или не совсем верен, так как основной чертой успешного бизнеса является его постоянное развитие. Именно поэтому лидером должен быть выбран тот работник, который сможет поднять бизнес на очередной уровень, а также не потерять (из-за отсутствия организаторских способностей) своих навыков долгосрочного и эффективного планирования работы порученного ему отдела. Лидер может и не быть начальником своего отдела, просто руководство должно оказывать всяческую поддержку (в том числе и материально-премиальную) его идеям. Само присутствие лидера-вдохновителя команды может стать неплохим мотивационным фактором для коллектива, поскольку лидер в глазах начальства и всего коллектива должен быть первым кандидатом на пост нового менеджера соответствующего отдела. Ситуация, когда в коллективе имеется два лидера, вполне возможна, однако она должна быть сведена до минимума по своей продолжительности, иначе другие сотрудники станут пассивными исполнителями чужих идей, а конкуренция между наиболее успешными сотрудниками начнет сводить их общие усилия на нет, повергнув компанию в пучину бюрократии. В этой ситуации многие менеджеры рекомендуют произвести наиболее успешного лидера в начальники отдела, в котором он был занят. Второго же лидера стоит переориентировать на новый, сходный с предыдущим круг задач, правда, не связанный с ним "политическими" нитями. Если управленческая структура компании матричная, то второй лидер обычно перебрасывается на новый, затеянный им же проект, в ходе которого ему разрешается выбирать себе помощников из числа старой команды.
Важно вовремя разглядеть лидера. Он может "скрываться" под "личиной" генератора идей. В крайнем случае, ему даже необязательно быть хорошим организатором, так как тандем талантливого идейного лидера и умелого менеджера может явиться куда более эффективным, чем посредственный управленец, занимающийся еще и стратегией отдела (компании).
Также стоит понимать, что сотрудник, однажды возведенный на пьедестал лидера, все-таки должен контролироваться начальством. Во многих организациях для поддержания на должном уровне исполнительской дисциплины необходимо корректировать поведение даже самых высокопоставленных лиц. Руководителям на любом уровне управления следует постоянно стремиться к усовершенствованию своих сильных сторон и к искоренению недостатков. Когда у служащих есть для этого мотив, необходимые ресурсы и поддержка, они могут достичь намеченной цели, изменив свои поведенческие шаблоны и приобретая новые навыки и умения. В организации следует создать такую атмосферу, чтобы служащие с высоким лидерским потенциалом сами заботились о своем дальнейшем развитии, при этом организации не должна пускать столь важный управленческий процесс на самотек. Для этого организация должна обеспечивать работников с высоким потенциалом, получивших новое назначение и выполняющих планы своего развития, консультационной и материальной поддержкой. В любом случае, новые практические задания и назначения, требующие значительных усилий, - такие, как расширение должностных обязанностей или участие в работе целевой группы, - оказывают на людей большее воздействие, чем опыт, приобретенный в ходе тренингов. Поэтому неординарные тестовые задания должны стать для любого менеджера нормой. Правда, с точки зрения правильной мотивации, эти инициативы (прдусматривающие дальнейшее развитие служащего) должны оказывать умеренное влияние на цели его текущего рабочего задания, не добавляя излишней ответственности к имеющимся основным задачам, иначе это только отпугнет подчиненного от их выполнения.

Системный взгляд

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

Служба поддержки проектов

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

Внедрение ИС: через тернии к звездам

Мирон Старченко, Эрнст Долгий
IT Manager #5(11)/2003
Представьте себе типичный промышленный город Н-ск где-то в глубине России. Утро. Заводские гудки заставляют проснуться и бежать на работу, легкий дым не дает забыть о близлежащих заводах, ну а если вы отъедете от города, то множество бревенчатых изб вам напомнят про самобытность России. Согласитесь, это все отдает прошлым веком и не дает забыть о некогда популярной механизации. Но сейчас на дворе иной век и теперь изобретена новая панацея от всех бед - автоматизация. Как вы думаете, а она поможет нашему Н-ску?
Сегодня для любого современного предприятия собственная информационная система столь значима, что сбои в ее работе могут привести к необратимым последствиям для него самого. Кроме того, бизнес-процессы и информационные технологии в современном офисе тесно взаимосвязаны, а значит, внедрение новой информационной системы необходимо рассматривать исключительно как изменение в организации работы предприятия в целом. В результате любой реинжиниринг лучше выполнять по хорошо продуманному плану, используя технологии Project Management и другие методики успешной реализации проектов, в том числе принципы формирования функциональных команд.
Обычно для внедрения изменений, связанных с ИС предприятия, используется методика Джона Коттера - своеобразного гуру по вопросу управления изменениями в организациях. В своей книге "Leading Change" он выделил восемь стадий, которые необходимо пройти, чтобы добиться положительных результатов.
Первая стадия, названная Коттером, - создание ощущения крайней необходимости предлагаемых интегратором изменений. И хотя каждый современный менеджер знаком с тезисом о том, что процесс повышения эффективности труда в организации - процесс бесконечный, многие руководители все же противятся нововведениям во вверенных им коллективах. Зачастую они попросту ленятся делать что-либо, если существующий уровень эффективности работы предприятия приемлем для них самих или для их руководства. Поэтому первоначальная задача интегратора новой информационной системы заключается в том, чтобы создать на предприятии своеобразную "революционную ситуацию", в рамках которой и "низы" не смогут жить по-старому, и "верхи" откажутся это делать привычным образом. Иными словами, любые изменения в организации предприятия должны быть четко аргументированы, а коллектив должен быть, как минимум, лоялен к ним или даже заинтересован в предлагаемой "революции".
"Хитрость", способная заинтересовать работников организации в нововведениях, - вторая стадия внедрения изменений Коттера. Она заключается в том, чтобы вовлечь в функциональную группу (которая, собственно, и займется реинжинирингом ИС) представителей руководства компании. Это, несомненно, повысит доверие к реинженерам информационной системы со стороны коллектива компании, а также в значительной степени стимулирует его к различным положительным проявлениям относительноу внедрения нововведений.
После того как будет сформирована функциональная группа внедрения проектов, не мешало бы выработать совместное виденье перспектив и стратегий, которыми должен руководствоваться не только реинженер, но и его функциональная группа. На практике каждый член коллектива должен представлять конечную цель изменений, производимых консультантом. Для этого необходимо "втянуть" коллектив в разработку целей или хотя бы грамотно разрекламировать их, что вполне по силам даже начинающим интеграторам. При этом важно, чтобы осваиваемые рубежи притягивали, а не отпугивали сотрудников организации. Отношение к проекту, уже на начальной стадии его выполнения, должно быть максимально доброжелательным.
Еще одна ступень правильного внедрения изменений организации по Коттеру - четвертая - касается передачи полномочий широкой группе активистов внедрения. Люди должны сообща работать над достижением общей цели, которую ранее усвоили и приняли "как свою". В конце концов, каждый член организации должен с чистой совестью сказать, что он и именно он, а не коллектив в целом, явился инициатором и подвижником "больших изменений". Впрочем, данная ступень, по мнению Коттера, является прямым следствием предыдущей. (Предыдущий шаг - члены коллектива должны видеть то же, что и "руководящая коалиция".)
Из современной теория продуктивной мотивации следует: достижение краткосрочных побед - важнейший элемент успеха и поощрения функциональных команд и коллективов в целом. Ничто так не воодушевляет людей на новые победы, как достижение результата. Пусть небольшого и промежуточного, но все-таки результата. Поэтому любые положительные достижения необходимо популяризировать в коллективе, а победителей "венчать в лучах славы". Это может быть осуществлено в виде закрепления достижений и дальнейшего проведения изменений, которое в модели Коттера является следующим шагом на пути к успеху. Организация должна стабильно продвигаться к изменениям, без отстающих и особо опережающих субъектов. Это приведет к укоренению новых подходов в корпоративной культуре и изменению отношения к реинжинирингу от новаторского к "рутинному" и повседневному. В итоге, изменения должны стать чем-то само собой разумеющимся и, кроме того, быть закреплены в регламентах и процедурах компании.

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

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

"Замыленный взгляд"

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

IT консалтинг - статьи

Инструменты виртуализации

Оценить производительность того или иного продукта для виртуализации можно по количеству виртуальных сред, которые одновременно могут быть запущены в базовой операционной системе. Как правило, эмуляторы компьютеров не очень эффективно могут управлять ресурсами серверов. Поэтому продукты VMware и Connectix могут исполнять на одном компьютере несколько десятков VE, хотя каждая среда могут содержать свою операционную систему. Эти продукты хорошо использовать для консолидации в гетерогенных системах, но их эффективность на приложениях, написанных для одной определенной среды, будет сомнительна.
Есть также две технологии для виртуализации Linux-приложений, которые распространяются в исходных текстах: User Mode Linux (UML) и Bochs, которая по идеологии похожа на предложения VMware. Имеется несколько аналогичных проектов для FreeBSD на основе Jail. В частности на основе Jail российской компанией ISPserver разработан продукт IspBSD, в котором не реализована поддержка кластерных конфигураций. При их оценке нужно смотреть на производительность и масштабируемость, а также на независимость процессов разных виртуальных сред. Одним из наиболее проработанных на сегодняшний день продуктов является система Virtuozzo.
Virtuozzo существует в вариантах для Linux и FreeBSD и поддерживает многопроцессорные конфигурации. Версия для Linux тестировалась только для платформы Intel; пока не было необходимости переносить ее на другую аппаратную архитектуру. В планах компании разработать аналогичные продукты для Solaris и Windows.
В Virtuozzo стремились не только добиться разделения ресурсов компьютера на виртуальные среды, но и оптимизировать их использование. Одним из методов для достижения этого является совместное использование несколькими средами не изменяемых объектов, таких как файлы программ и библиотек, а также неизменяемые сегменты кода в оперативной памяти. Именно использование этих методов оптимизации позволяет Virtuozzo поддерживать несколько тысяч виртуальных сред на одном физическом компьютере.

Консолидация и виртуализация

Установив в компании один производительный и надежный сервер, можно заменить им несколько маломощных машин, при этом общая стоимость владения таким высокопроизводительным сервером, как правило, оказывается ниже. Правда уменьшится и общая надежность системы.
Стоимость оборудования при использовании более дорогого сервера увеличится, но упростится его техническое сопровождение, а следовательно и общая стоимость владения. В конфигурации двух компьютеров с общим RAID-массивом можно максимально уменьшить время простоя системы после сбоя и перенести виртуальную среду на другой компьютер практически мгновенно. При сбое одного компьютера работа приложений может быть тут же восстановлена на другом — потеряны будут только самые оперативные данные, хранившиеся в кэш-памяти остановившейся машины. Таким образом, консолидация позволяет уменьшать затраты, которые вносят максимальную долю в TCO.
С использованием виртуализации упрощается перенос приложений с одного сервера другой. Этот процесс, как правило, можно выполнить безболезненно — штатной операцией перемещения виртуальной среды. В результате, появляется возможность физически передвигать приложения к месту их оптимального использования. Например, если компания имеет центры обработки данных по всему миру, то с помощью виртуализации она сможет перемещать приложения туда, где они наиболее востребованы.

Консолидация

Следует выделить два типа консолидации: физическую и логическую. При выполнении физической консолидации серверы физически перемещаются в единый информационный центр, при этом их представление в компьютерной сети может оставаться прежним, то есть за одним физическим сервером может быть закреплено несколько сетевых сервисов. Логическая консолидация - это объединение вычислительных ресурсов серверов возможно без их физического перемещения в единый сетевой ресурс. Сейчас необходимые для этого решения начинают появляться. В частности, они позволяют управлять сетью из нескольких физических серверов как единым устройством.
Сформулируем набор требований, которым должна удовлетворять процедура консолидации, чтобы ее применение было экономически оправданным: доступность пользовательских приложений после консолидации не должна измениться; стиль работы пользователей с приложениями не должен усложниться; информационная безопасность не должна ухудшиться; нужно обеспечить значительное снижение общей стоимости владения информационной системой.
Самый простой пример применения консолидации — слияние двух и более компаний с различными информационными системами. В этом случае консолидация позволяет принести экономию средств за счет исключения дублирующих элементов и эффективного использования уже существующих ресурсов. Другим примером является консолидация информационных систем филиалов. Здесь важна логическая консолидация, которая позволит центральному офису контролировать работу информационных систем филиалов.
При перенесении ресурсоемких приложений на централизованные серверы можно снизить стоимость рабочего места, воспользовавшись для их организации более дешевыми компьютерами, на которых работает строго фиксированный набор программ — в идеале, только браузер. Объединение серверов в едином центре обработки данных позволяет усилить их защиту и увеличить надежности вычислений. Это относится как к физической безопасности (организация доступа к аппаратуре), так и сетевой (удаленный доступ). Это же относится и к надежности, поскольку в централизованном вычислительном центре проще обеспечить оптимальные условия окружающей среды, надежное электропитание, постоянное резервное копирование и быстрое выполнение регламентных работ, чем в распределенной системе.
В каждом конкретном случае можно использовать свои методы и стратегии консолидации, которые позволили ее оптимизировать. Тем не менее, есть универсальное решение — виртуализация, которая в общем случае позволяет менять физическую и логическую конфигурацию информационной системы.

Рис. 2. Логическая консолидация

Оптимизация

Наиболее объемные элементы программ — разделяемые библиотеки, которые являются стандартными практически для всех виртуальных сред, да к тому же не меняются в процессе исполнения программы. Это позволяет использовать их сразу во всех средах, делая ссылку на эту физическую область. В Virtuozzo это реализовано с помощью функции mmap, которая обеспечивает работу с картами памяти. Если же процесс имеет право на изменение общего кода, то ядро вначале копирует этот сегмент в свободную область памяти, а только потом изменяет его содержимое.
Аналогичный механизм оптимизации используется и дисковых накопителей. Для его поддержки разработчики SWsoft реализовали дополнительную прослойку между VFS - виртуальной файловой системой Unix, и драйверами физических файловых систем, таких как ext2, RaiserFS или других. Эта прослойка, называемая VZFS, обеспечивает хранение не изменяемых файлов в единственном экземпляре. Эта прослойка также позволяет реализовать механизм копирования при записи и оптимизацию по памяти, описанную выше.
При использовании подобной системы оптимизации важно правильно решить проблему модернизации программного обеспечения. Эту операцию логично делать централизованно, чтобы модернизированные программы также имели на диске только одну копию. Для реализации такой возможности в SWsoft разработала специализированный инструментарий централизованного обновления.

Особенности виртуализации

Виртуальная среда имеет свою файловую систему, а также доступ к части процессорного времени, памяти и периферийных устройств, такой как сетевая плата. Виртуальных сред на одном компьютере может работать несколько; они тем или иным образом распределяются по всем процессорам, памяти и дискам. Поэтому VE, как правило, не зависят от аппаратуры и могут легко перемещаться с одного компьютера на другой. Кроме виртуальных сред есть базовая операционная система, которая объемлет все виртуальные среды. Именно она скрывает подробности аппаратуры и занимается управлением реальными ресурсами компьютера.
Основной задачей технологии виртуализации является обеспечение жесткого разделения ресурсов различных виртуальных сред. Это условие подразумевает, что процесс, запущенный в одной виртуальной среде, не может получить доступ к файлам, памяти и процессам, принадлежащим другим виртуальным средам. Необходимо обеспечить нормальное взаимодействие процессов внутри виртуальной среды, ограничивая доступ к элементам извне.
Все взаимодействия виртуальной среды с внешним миром выполняются через сеть. Локальные методы взаимодействия, такие как сокеты или другие характерные для Unix способы межпроцессной связи наподобие каналов, открываемых между приложениями разных виртуальных сред, блокируются. Это необходимо как для соблюдения правил безопасности, так и для обеспечения переносимости виртуальной среды на другой компьютер. В частности взаимодействие через сеть дает возможность использовать для защиты приложений традиционные сетевые средства защиты, такие как межсетевые экраны, датчики вторжений, сканеры защищенности и другие. Перемещение виртуальных сред с одного компьютера на другие позволяет организовать балансировку нагрузки, перемещение приложений туда, где они наиболее востребованы, и упростить техническое обслуживание аппаратуры.

Продукты сопровождения

Продукция SWsoft состоит из трех групп: собственно операционная среды Virtuozzo, система управления ресурсами и поддержка кластерной конфигурации, при которой виртуальная среда может перемещаться с одного базового компьютера на другой. Быстрое перемещение виртуальной среды с компьютера на компьютер используется для балансировки нагрузки, проведения регламентных работ и быстрого восстановления после сбоев. Для быстрой миграции виртуальных сред была разработана удобная утилита, которая позволяет установить среду на одном компьютере, передать данные виртуальной среды на другой и восстановить ту же среду на другом компьютере.
Все утилиты, поставляемые SWsoft, можно разделить на две большие части: управления и сбор статистики. Утилиты управления включают программы для создания, конфигурирования, перемещения и уничтожения виртуальных сред, а так же для управления программным обеспечением и шаблонами, которые и позволяют эффективно использовать дисковое пространство. Система мониторинга собирает информацию об использовании ресурсов компьютера виртуальными средами.
У SWsoft есть продукт HSPcomplete — надстройка над Virtuozzo, имеющая множество функций для управления системой из нескольких физических серверов. Продукт предназначен для провайдеров, предоставляющих на основе Virtuozzo услуги по аренде виртуальных серверов. Так, в HSPcomplete встроена система биллинга и определенный интеллект, позволяющий решать бизнес-задачи.
В SWsoft собирается разрабатывать распределенную файловую систему, которая позволяла бы организовать распределенное хранение данных с некоторым уровнем избыточности. При выходе из строя одного устройства хранения данные из системы не исчезают, а извлекаются из копии, расположенной на другом устройстве. Реализация подобной файловой системы позволила бы ускорить восстановление после сбоя и перемещение виртуальных сред на другие компьютеры. Уже есть установки Virtuozzo в «Русь-Банке», где этот продукт используется для консолидации серверных ресурсов.

Разделение ресурсов

В Virtuozzo поставили себе цель, чтобы виртуальные среды не имели никакой информации о «железной» конфигурации сервера. Все псевдофайлы в каталоге /dev/ остаются, но обращение к ним передается в базовую ОС и только затем на драйвера разделяемых ресурсов. Проблемы могут возникнуть в том случае, если приложению необходим прямой доступ к аппаратуре, однако большинство протестированных приложений не требовало такого доступа, то есть корректно работало в виртуальной среде.
Более сложная ситуация с файловой системой /proc, в которой находится справочная информация о ядре, по процессам и периферии. Здесь соблюдается то же самое правило: информация о системе в целом доступна, а по конкретному оборудованию, такому как шины, память и процессор — нет. В некоторых случаях из псевдофайлов этого каталога приложение может получить информацию об отдельной виртуальной среде, а в некоторых — по серверу в целом. В частности, такое различие может быть важно для оценки загруженности процессора: для некоторых программ достаточно выдавать информацию о виртуальной среде, а в некоторых — общую нагрузку на процессоры. При этом разработчики стремились обеспечить выполнение уже существующих приложений без перекомпиляции.
Внутри виртуального сервера нет прямого доступа к сетевому интерфейсу. Все операции с сетью выполняются с помощью стандартных функций ядра, реализация которых в Virtuozzo существенно изменена. Каждой виртуальной среде выделяется определенная гарантированная полоса пропускания внешнего канала и возможность взаимодействия с другими средами того же сервера в рамках концепции виртуальной сети. Причем при необходимости можно реализовать различные способы IP-нумерации: отдельный IP-адрес на каждую среду, общий IP-адрес с разделением по DNS-имени или трансляция адресов в рамках виртуальной сети. Такая организация работы с сетью необходима для того, чтобы приложение виртуальной среды не могло подглядеть передачу данных по сети другими виртуальными средами, обратившись для этого напрямую к драйверу Ethernet. Реализованы эти функции с помощью специальной прослойки в ядре, которая дает каждой среде свой отдельный виртуальный сетевой интерфейс API, аналогичный сетевому интерфейсу самой ОС Linux.

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

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

Виртуализация

Под виртуализацией подразумевается технология, который позволяет разделить один физический сервер на несколько виртуальных. Можно выделить два основных типа виртуализации: аппаратную и программную. Аппаратная виртуализация использует некоторые особенности платформы и использовать ее на устройствах другого производителя, как правило, не удается. Примерами такой виртуализации являются мэйнфреймы с разбиением по разделам (partitioning), серверы-лезвия и решения, подобные Sun Enterprise 10000, в которых один физический сервер можно разделить на несколько. При этом за каждым сервером, как правило, закрепляется свой набор ресурсов; автоматически менять это распределение приложения не могут.
В большинстве же случаев для консолидации лучше подходят программные решения, которые предполагают создание в рамках одной операционной системы нескольких виртуальных сред (Virtual Environment — VE), в которых приложения работают не могут напрямую взаимодействовать с программами из других VE. Примерами таких продуктов является VMware, Connectix и Virtuozzo. Все они работают на так называемых серверах стандартной архитектуры (т.е. x86), хотя разработчики Virtuozzo не видят проблем в переносе их продукта на другие аппаратные платформы.
Программную виртуализацию можно разделить на два подтипа: эмуляция компьютера или создание виртуальной среды исполнения. В первом случае эмулятор позволяет исполнять в одной операционной системе приложения, написанные для другой. Виртуализация среды исполнения позволяет запускать в VE только приложения одной определенной операционной системы. Эмуляторами компьютеров являются продукты VMware и Connectix. Они, как правило, не очень эффективно используют ресурсы сервера, поскольку значительные их часть тратится на преобразование форматов данных и переключение контекста различных ОС. Так виртуализация компьютера позволяет запустить на одном физическом сервере всего несколько виртуальных. С помощью виртуальных сред исполнения можно добиться большей эффективности и расслоить один сервер на тысячи отдельных VE. Для консолидации используются оба эти подхода, поскольку в некоторых случаях важна работа приложений, предназначенных для различных платформ, а в некоторых — эффективность получившегося решения.



    Работа с информацией: Cистемы - Технологии - Рынок

• Анализ информационных систем
  
• Методы информационных систем
  
• Интернет как информационная система
  
• Искусственный интеллект в информационных системах
  
• Обработка информации информационными системами
  
  
• Информационные системы в офисе
  
• Управление информационными системами
  
• Технологии информационных систем
  
• Теория информационных систем
  
• Почта - информационная система
  
  
• Outlook и информационные системы
  
  
• Информационный рынок
  
• Информационный рынок - IT
  
• Технологии информационного рынка
  
• Безопасность на информационном рынке