Документооборот - статьи

Документ (document или transaction set)

Стандарт X12 оперирует понятием «документ» (document), или «набор транзакции» (transaction set). Документ – это набор данных, представляющих в совокупности законченную информацию, ценную для сторон, участвующих в документообороте.
Transaction set в большинстве случаев - это обычный документ, который компании используют в своей работе – например Invoice (счет) или Purchase Order (ордер заказа).

Функциональная группа (Functional Group)

Функциональная группа – это группа (набор) одинаковых по типу документов (ордеров, инвойсов и т.д.), которые входят в Interchange. Структура EDI будет описана дальше, но пока просто отметим, что начало и конец функциональной группы определяются сегментами GS/GE (GS/GE Envelope). Тип функциональной группы определяется элементом GS-01 (например, функциональная группа PO содержит ордера заказов – Purchase Orders, функциональная группа IN - инвойсы). Сегмент GS так же иногда служит для маршрутизации документов между подразделениями партнера-получателя документов.

Header (заголовок), Details (детали) и Summary (итог)

Наконец, рассмотрим сам документ (transaction set). Как уже было сказано выше, документ (transaction set) представляет собой набор данных, представляющих в совокупности законченную информацию, ценную для сторон, участвующих в документообороте. Примеры документов – ордер, счет, документ с информацией о скидках, каталог и т.д. Каждый документ заключен в «конверт» ST/SE, в котором указан тип документа. Документ, в свою очередь, разделен на три группы – Header (заголовок), Details (детали) и Summary (Итог).
рис 6.
Заголовок документа содержит данные, общие для документа – например номер, контактная информация, даты погрузки/доставки, адреса и т.д.
В деталях документа включено содержание документа, например для ордера заказа – информация о заказанном товаре, количество, цена и скидки на данный тип товара.
Итоговые данные обычно содержат суммарную информацию – для ордера это может быть количество типов заказанных товаров, для счета – общая стоимость товара, общие скидки и т.д.

Interchange

Interchange это структурированный (согласно правилам, определяемым стандартом X12) набор данных, которым обмениваются партнеры по (электронному) документообороту.
Interchange – это больше, чем просто документ, скорее это пакет групп документов (хотя interchange может содержать всего одну группу с одним документом).
В дальнейшем я буду использовать термин «EDI документ» если речь идет об Interchange и просто «документ» если речь идет об отдельном документе (transaction set) из этого Interchange.
Можно изобразить структуру Interchange таким образом (позже мы разберем составляющие части и структуру более подробно):
рис 1.
Interchange начинается сегментом ISA и заканчивается сегментом IEA (ISA/IEA Envelope). ISA сегмент используется в том числе для маршрутизации документа между партнерами, участвующими в документообороте.
X12 определяет каждый EDI документ как набор сегментов и элементов, которые определяют этот документ, утверждает порядок следования сегментов в документе, порядок следования элементов в сегменте и отношения между сегментами и/или элементами.
В X12 каждому специфичному документу, например инвойсу (invoice), ордеру заказа (PO, purchase order) соответствует специальное имя – трехзначный номер-идентификатор. Например, invoice это 880, PO – 850, Ship Notice/Manifest – 856 и т.д. С полным набором можно ознакомиться, например, по адресу
Как выглядит EDI документ (пример):
ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~ GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~ ST*850*50001~ BEG*00*SA*ASNTESTORD**20060615~ PER*BD*DON SMITH~ PER*DC**TE*(123) 456-7890~ FOB*PP~ DTM*002*20060625~ DTM*010*20060618~ N1*ST*A1 STORES*93*0655~ N3*142 WAGON DRIVE~ N4*MIDDLETOWN*AR*72222~ N1*BT*A1 STORES*93*0655~ N3*75 CROSS ROAD~ N4*MIDDLETOWN*AR*72222~ PO1*001002003*10*EA*15**BP*123456411~ PID*A****ADIDAS BLUE T-SHIRT~ ITA*A***CC***1000~ PO1*002003004*20*EA*20**BP*123456817~ PID*A****NIKE RED T-SHIRT~ ITA*A***CC***1500~ PO1*003004005*10*EA*10**BP*123456908~ PID*A****PUMA WHITE T-SHIRT~ ITA*A***CC***1200~ PO1*004005006*10*EA*15**BP*123456321~ PID*A****REEBOK T-SHIRT~ ITA*C***CB***1400~ PO1*005006007*10*EA*20**BP*123456287~ PID*A****UMBRO UEFA CUP T-SHIRT~ ITA*A***CC***1600~ PO1*006007008*20*EA*1**BP*123456413~ PID*A****DEMIX BLUE T-SHIRT~ ITA*A***CC***1800~ CTT*6~ SE*33*50001~ GE*1*5~ IEA*1*000000005~ Следует отметить, что в данном примере переносы строк между сегментами поставлены специально, чтобы можно было легче "увидеть" структуру данных.
На самом деле, переносы строк не используются (либо игнорируются) и данный EDI документ в оригинале должен был бы выглядять так, в виде "одной строки":

ISA*00**00* *ZZ*A1STORES *ZZ*LEXINGTON 020115*0900*U*00400*000000005*0*T*>~GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~ST*850*50001~BEG*00*SA*ASNTESTORD**20060615~PER*BD*DON SMITH~PER*DC**TE*(123) 456-7890~FOB*PP~DTM*002*20060625~DTM*010*20060618~N1*ST*A1 STORES*93*0655~N3*142 WAGON DRIVE~N4*MIDDLETOWN*AR*72222~N1*BT*A1 STORES*93*0655~N3*75 CROSS ROAD~N4*MIDDLETOWN*AR*72222~PO1*001002003*10*EA*15**BP*123456411~PID*A****ADIDAS BLUE T-SHIRT~ITA*A***CC***1000~PO1*002003004*20*EA*20**BP*123456817~PID*A****NIKE RED T-SHIRT~ITA*A***CC***1500~PO1*003004005*10*EA*10**BP*123456908~PID*A****PUMA WHITE T-SHIRT~ITA*A***CC***1200~PO1*004005006*10*EA*15**BP*123456321~PID*A****REEBOK T-SHIRT~ITA*C***CB***1400~PO1*005006007*10*EA*20**BP*123456287~PID*A****UMBRO UEFA CUP T-SHIRT~ITA*A***CC***1600~PO1*006007008*20*EA*1**BP*123456413~PID*A****DEMIX BLUE T-SHIRT~ITA*A***CC***1800~CTT*6~SE*33*50001~GE*1*5~IEA*1*000000005~ Однако в дальнейшем для удобства я буду отделять сегменты друг от друга переносом строки.

Вернемся к примеру EDI документа. По сегменту GS, который идет вторым, можно определить, что это EDI документ стандарта X12 (X), версия 4010 (004010). По сегменту ST можно сказать, что это 850 документ, или Purchase Order (ордер заказа). По остальному содержанию можно определить, что речь идет о заказе футболок различных фирм, узнать их цену и количество. О том, как читать документы будет рассказано дальше, но пока вы можете сами попытаться «понять» данный пример.

Использование EDI в реальном документообороте

Электронный документооборот используется во многих областях деятельности, где требуется обмен данными. Это в первую очередь торговля, страхование, медицина, транспортная логистика и т.д.
Крупные розничные сети (ритейлеры), типа Wal-Mart, Kroger, K-Mart и другие используют EDI X12 для обмена электронными документами со своими торговыми партнерами. Они задают формат документов, которые они отправляют сами и которые они ожидают от поставщиков. Компании-поставщики, которые хотят работать с этими ритейлерами, обязаны использовать эти форматы – иначе они не смогут «понять», что заказывает ритейлер или в компании-ритейлере не смогут «понять» инвойс.
Обычно набор документов, которыми обменивается ритейлер с поставщиками, включает в себя следующие документы:

PO (Purchase Order, ордер заказа) – какой товар, сколько единиц его и т.д. заказано. Отправляет ритейлер.

ASN (Advanced Ship Notice/Manifest) - документ по комплектации и упаковке товара, например 10 паллетов, на каждом по 4 коробки, в каждой коробке по 100 единиц товара. Вес такой-то, объем - такой-то. Отправляет поставщик.

Invoice (Инвойс или счет(-фактура)) - счет за товар. Отправляет поставщик.

Remittance Advice - подтверждение оплаты. Отправляет ритейлер.

FA (Functional Acknowledgement) – специальный тип документов, которые отправляются автоматически в ответ на полученный EDI документ (подтверждают получение) и содержат информацию о нераспознаных/необработанных данных (если таковые имеются)

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

История

Электронный документооборот EDI (Electronic Data Interchange) – обмен между компьютерами структурированной информацией по взаимосогласованным правилам.
Впервые EDI начал применяться в середине 60х годов в сфере железнодорожных и автомобильных перевозок. В 1968 году был организован комитет United States Transportation Data Coordinating Committee (TDCC) для работ над стандартом электронного документооборота для данной индустрии. В дальнейшем работой по расширению и усовершенствованию стандарта стал заниматься .
Стандарт электронного обмена документами ANSI ASC X12 (American National Standards Institute Accredited Standards Committee X12) был разработан в 70-х годах, когда был важен малый размер электронного документа (для модемов со скоростями 300-1200 бит в секунду) и каждый байт должен был нести максимум информации. Таким образом, от «читаемости» электронного документа отказались в пользу «плотности информации». В то время коммуникации между компаниями были далеки от идеала, и нередки были случаи «обрыва» линии и потери данных. Поэтому формат электронных документов разрабатывался в том числе с целью сохранения целостности данных, для чего были использованы механизм «конвертов» (envelopes) и контрольные числа, которые позволяли проверять, что переданные данные небыли нарушены или потеряны.
Стандарт EDI можно определить как набор правил, определяющих структуру и формат EDI документа.
Существует несколько организаций, которые в данный момент работают над стандартами EDI:

ANSI (American National Standards Institute) – это Институт, который устанавливает стандарты для многих видов деятельности. EDI занимается Комитет ANSI X12 – главная организация США по стандартизации EDI.

EDIA (The Electronic Data Interchange Association, раннее известная как Transportation Data Coordinating Committee (TDCC))

AIAG (The Automotive Industry Action Group) – группа стандартов для автомобильной промышленности. Данный стандарт является подгруппой стандартов ANSI X12.

UCS (The Uniform Communications Standard) стандарт, используемый для бакалейной индустрии.

EDIFACT (Electronic Data Interchange for Administration, Commerce, and Transport.) – Организация, занимающаяся стандартизацией EDI при Совете по Экономике и Социальной политике ООН. Стандарты EDIFACT, в отличии от ANSI X12, используются в основном в Европе, в то время как X12 – в Америке.

ODETTE (The Organization for Data Exchange by Tele-Transmission in Europe.)

VICS (The Voluntary Inter-industry Communication Standards) – организация, которая является подгруппой ANSI X12 и занимается стандартами для индустрии розничной торговли.

Стандарт EDI ANSI ASC X12 (далее – просто X12) включает в себя описание форматов документов (наборов транзакций - transaction sets) и имеет различные версии (связанные с развитием стандартов) - 4030VICS, 5010 и т.д.

Элемент

Элемент (element) сегмента – это «квант» информации, содержащейся в сегменте. В описании сегмента, сделанном выше, понятно, как сегмент состоит из элементов.
рис 6.
Следует отметить, что элемент вне сегмента не имеет смысла.
Элементы в сегменте имеют свой «адрес», который состоит из имени сегмента и позиции элемента в данном сегменте. Обычно обозначается как
<ИМЯ СЕГМЕНТА>-<ПОЗИЦИЯ>
Или
<ИМЯ СЕГМЕНТА><ПОЗИЦИЯ>
Например, PO101 или PO1-01 для первого (01) элемента в сегменте PO1.

Конверт (Envelope)

Чтобы нагляднее представить структуру EDI документа, можно провести аналогию между ним и обычными бумажными документами, которые запечатаны в конверты (envelopes).
Самый верхний конверт (ISA/IEA Envelope) содержит внутри себя один или более конвертов (GS/GE Envelopes), в которых содержатся непосредственно сами документы, каждый в отдельном конверте (ST/SE Envelopes).
На конверте ISA/IEA «написаны» адреса компании-получателя и компании-отправителя.
На конверте GS/GE «написан» тип документов, которые в нем находятся. В таком конверте содержатся только документы одного типа – ордера, инвойсы и т.д. Так же на этом конверте может быть «написано», в какое подразделение компании-получателя направлены конечные документы.
Наконец самые последние конверты содержат непосредственно конечные документы – например, ордера заказа номер 000000123 и 000000124.
Можно изобразить структуру EDI-документа для наглядности так:
ISA <<< «верхний» конверт
GS <<< «внутренний» конверт, содержит документы одного типа
ST <<< конверт с документом
<документ 1> <<< непосредственно сам документ
SE
...
ST
<документ X>
SE
GE
... GS
ST
<документ 1>
SE
...
ST
<документ Y>


SE
GE
IEA

Наш пример:

ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~
GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~
ST*850*50001~
BEG*00*SA*ASNTESTORD**20060615~
...
CTT*6~
SE*33*50001~
GE*1*5~
IEA*1*000000005~

Конверты (envelopes)

Существуют три типа конвертов – ISA/IEA Envelopes, GS/GE Envelopes и ST/SE Envelopes. Начальные сегменты конвертов имеют название Header, а завершающие – Trailer:

ISA - Interchange Control Header

GS - Function Group Header

ST - Transaction Set Header

SE - Transaction Set Trailer

GE - Function Group Trailer

IEA - Interchange Control Trailer

Рассмотрим эти сегменты подробнее.
ISA (Interchange Control Header) – сегмент, который определяет отправителя и получателя документа.
Важно, что элементы этого сегмента имеют фиксированную длину, например ISA-06 имеет размер 15/15 и до нужной длины дополняется пробелами, в итоге, вместо *A1STORES* мы имеем *A1STORES*. Это свойство используется для определения разделительных элементов, которые используются в данном EDI документе. Символ окончания сегмента берется из позиции 106 (~), разделитель элементов – из позиции 4 (*). Разделитель суб-элементов в композитном элементе находится в позиции 105 (>).
ISA*00* *00* *ZZ*A1STORES *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~

Элемент	Описание	Тип данных	Значение	Комментарий
ISA-01	Authorization Information Qualifier	M ID (101) 2/2	00	Тип авторизации (определяется в ISA-02) 00 – No Authorization present
ISA-02	Authorization Information	M AN 10/10	“ ” (10 пробелов)	Информация, которая используется для дополнительной идентификации или авторизации отправителя EDI документа или данных, которые в нем находятся.
ISA-03	Security Information Qualifier	M ID (103) 2/2	00	Тип security информации, содержащейся в ISA-04. 00 – No Security Information present. 01 – Password.
ISA-04	Security Information	M AN 10/10	“ ” (10 пробелов)	«Пароль» документа. Этот элемент почти не используется по назначению.
ISA-05	Interchange ID Qualifier	M ID (105) 2/2	ZZ	Идентификатор типа данных элемента ISA-06. В нашем примере это ZZ – взаимно определенные значения, но часто используются также 01 – DUNS 02 - SCAC code 10 – DODAAC 16 – DUNS + 4 и другие
ISA-06	Interchange Sender ID	M AN 15/15	“A1STORES ”	Используется для определения отправителя документа
ISA-07	Interchange ID Qualifier	M ID (105) 2/2	ZZ	Идентификатор типа данных элемента ISA-08. В нашем примере это ZZ – взаимно определенные значения, но часто используются также 01 – DUNS 02 - SCAC code 10 – DODAAC 16 – DUNS + 4 и другие
ISA-08	Interchange Receiver ID	M AN 15/15	“LEXINGTON ”	Используется для определения получателя документа
ISA-09	Interchange Date	M DT 6/6	020115	Дата документа
ISA-10	Interchange Time	M TM 4/4	0900	Время документа
ISA-11	Interchange Control Standards ID	M ID (110) 1/1	U	Код, идентифицирующий агенство, которое отвечает за EDI стандарт, используемый в данном EDI документе. U - US EDI community
ISA-12	Interchange Control Version Number	M ID (111) 5/5	00400	Версия ISA/IEA Envelope
ISA-13	Interchange Control Number	M N0 9/9	000000005	Специальный идентификатор, который используется для проверки уникальности документа и предотвращения отправки дублицированных документов. Обычно используется целочисленное значение, и с каждым новым документом, отправленным одному и тому же партнеру, увеличивается на единицу.
ISA-14	Acknowledgement Requested	M ID (113) 1/1	0	Индикатор запроса сегмента TA3 (Interchange Delivery Notice Segment) в ответе принимающего сервиса. Этот сегмент (TA3) используется для определения, был ли EDI документ (interchange) доставлен конечному получателю, и некоторой другой вспомогательной информации.
ISA-15	Test Indicator	M ID (114) 1/1	T	Имеет два возможных значения – T (Test) или P (Production), и используется для определения типа документа. Можно использовать “T” для проверки правильности формата документа.
ISA-16	Subelement Separator	M (символ-разделитель) 1/1	>	Разделитель суб-элементов в композитном элементе.

IEA (Interchange Control Trailer) – замыкающий Interchange сегмент.

IEA*1*000000005~

Элемент	Описание	Тип данных	Значение	Комментарий
IEA-01	Number of Function Groups Included	M N0 1/5	1	Количество функциональных групп (ограниченных GS/GE сегментами), которые входят в данный Interchange. В нашем примере это 1 – одна функциональная группа (PO).
IEA-02	Interchange Control Number	M N0 9/9	000000005	Контрольный номер Interchange, совпадает с ISA-13

GS (Function Group Header) - сегмент определяет тип документа(ов), которые входят в эту группу, содержит контрольную информацию. Он может использоваться для роутинга EDI документа между различными системами и/или адресами компаний, которые обмениваются этими документами. Еще раз – GS/GE сегменты являются «конвертом» (envelope) для документов одного типа (тип определяется GS-01 сегментом).

GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~

Элемент	Описание	Тип данных	Значение	Комментарий
GS-01	Functional Identifier Code	M ID (479) 2/2	PO	Тип документов, включенных в данную функциональную группу. PO – ордера, IN – инвойсы и т.д. (см спецификацию).
GS-02	Application Sender’s Code	M AN 14/14	A1STORES	Код, идентифицирующий сторону-отправителя. Данный код согласуется партнерами по документообороту.
GS-03	Application Receiver’s Code	M AN 9/9	LEXINGTON	Код, идентифицирующий сторону-получателя. Данный код согласуется партнерами по документообороту.
GS-04	Date	M DT 8/8	20020110	Дата
GS-05	Time	M TM 4/4	0900	Время
GS-06	Group Control Number	M N0 1/9	5	Присвоенный отправителем номер.
GS-07	Responsible Agency Code	M ID(455) 1/2	X	Код, используемый для определения компании, выпустившей данный стандарт. X - Accredited Standards Committee X12, T - Transportation Data Coordinating Committee (TDCC)
GS-08	Version/Release/Industry Identifier Code	M AN 1/12	004010	Код, идентифицирующий номер версии, релиза и суб-релиза используемого стандарта. В нашем случае это версия стандарта - 4010.

GE (Function Group Trailer) - сегмент определяет конец данных, которые были начаты GS сегментом. В EDI-документ (Interchange) может быть включено несколько функциональных групп, сегмент GE используется для определения места, где завершается функциональная группа.

GE*1*5~

Элемент	Описание	Тип данных	Значение	Комментарий
GE-01	Number of Transaction Sets Included	M N0 1/6	1	Количество документов (transaction sets), включенных в данную функциональную группу. Используется как контрольное значение.
GE-02	Group Control Number	M N0 1/9	5	Присвоенный отправителем номер. Используется как контрольное число при определении GS/GE конверта (GS-06 = GE-02).

ST (Transaction Set Header) - сегмент идентифицирует тип документа. Этот сегмент начинает документ (например, ордер или инвойс). Как уже было сказано в начале, в X12 тип документа имеет трехзначный номер-идентификатор.

ST*850*50001~

Элемент	Описание	Тип данных	Значение	Комментарий
ST-01	Transaction Set Identifier Code	M ID(143) 3/3	850	Трехзначный номер-идентификатор, определяющий тип документа. Примеры: 850 - Purchase Order 810 - Invoice 855 - Purchase Order Acknowledgment 889 - Promotion Announcement
ST-02	Transaction Set Control Number	M AN 4/9	50001	Уникальный идентификатор документа в данной функциональной группы. Обычно (часто) используется последовательность 0001, 0002,… но бывают и другие (как в нашем примере).

SE (Transaction Set Trailer) - сегмент определяет конец документа. Этот сегмент содержит информацию об общем количестве сегментов с данными (включая ST и SE сегменты). Это число используется для верификации документа.

SE*33*50001~

Элемент	Описание	Тип данных	Значение	Комментарий
SE-01	Number of included segments	M N0 1/10	33	Количество сегментов, входящих в данный документ (transaction set), ограниченный конвертом ST/SE. Сами сегменты ST/SE так же подсчитываются в этом числе. Эти данные используются для контрольной проверки целостности документа после обработки – все ли сегменты были обработаны.
SE-02	Transaction Set Control Number	M AN 4/9	50001	Контрольный номер, SE-02 = ST-02 для каждого ST/SE конверта.

Опциональность элементов

Элементы сегмента имеют три типа опциональности:
M (mandatory) – обязательный элемент. Обычно обязательными элементами являются те, которые несут основную информацию сегмента. Например, в сегменте DTM (Date/Time Reference, описывает дату и/или время) элемент DTM-01 (Date/Time Qualifier, тип Даты и/или времени) обязателен, так как без него мы не могли бы определить, что именно это за дата. В нашем примере
DTM*002*20060625~
DTM*010*20060618~
Элементы DTM-01 имеют значения 002 и 010. Тип данных DTM-01 – ID, классификатор – 374 (Date/Time Qualifier, Code specifying type of date or time, or both date and time). По справочнику находим значения для 002 и 010:
002 Delivery Requested (запрашиваемая доставка)
010 Requested Ship (запрашиваемая погрузка)
Т.о. в документе указано, что для описанного товара дата погрузки – 18 Июня 2006 года, а дата доставки – 25 Июня 2006.
Если бы DTM-01 был бы опциональным (необязательным) элементом, и он бы отсутствовал в обоих сегментах, то получатель документа не мог бы определить, что это за даты.
O (optional) – необязательный, опциональный элемент. Эти элементы обычно несут второстепенную информацию, которая не обязательна для понимания информации, заключенной в сегменте. В нашем примере
PO1*004005006*10*EA*15**BP*123456321~
Можно заметить, что между элементами PO1-04 (значение 15) и элементом PO1-06 (значение BP) идет элемент PO1-05 который не имеет значения (пропущен). PO1-05 (Basis Unit Price Code, код, идентифицирующий тип цены единицы товара) является опциональным элементом. Этот элемент описывает тип цены, например BD (Before Discount, до скидки) или HF (Per 100 Feet, за 100 футов – например, для кабеля), или HP (Price per Hundred, цена за сотню) и т.д. В данном случае нам не нужно дополнительно указывать, что цена именно за единицу товара, поэтому в сегменте этот элемент пропущен.
C (conditional) – зависимый элемент, чья опциональность зависит от условий. В нашем примере:
PO1*004005006*10*EA*15**BP*123456321~
PO1-06 (Product/Service Id Qualifier, тип идентификатора товара/услуги) и PO1-07 (Product/Service Id, идентификатор товара/услуги) – примеры подобных элементов.
X12 определяет условие их опциональности так:

P0607 - If either PO1-06 or PO1-07 is present, then the other is required.

Тоесть если либо PO1-06, либо PO1-07 присутствует в сегменте, то второй – обязателен. В данном случае это очевидно – если есть идентификатор товара, то нам нужно знать его тип. И наоборот, если есть тип идентификатора, то было бы странно, если бы сам идентификатор отсутствовал.

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

Правила и ограничения

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

С (Conditional) - зависимость опциональности одного элемента(ов) от существования другого (первого в описании):

C0302 - If PO103 is present, then PO102 is required.

C060504 - If PR106 is present, then PR105 and PR104 are required.

P (Paired or multiple) - зависимость опциональности группы элементов (если хотя бы один из группы присутствует, то остальные обязательны):

P0607 - If either PO106 or PO107 is present, then the other is required.

P040506 - If either AT904, AT905 or AT906 are present, then the others are required.

L (List Conditional) – зависимость трех и более элементов между собой, когда в случае существования первого в описании элемента обязателен как минимум один из остальных:

L13101112 - If PO413 is present, then at least one of PO410, PO411 or PO412 is required.

R (Required) – обязательность как минимум одного из перечисленных элементов:

R1012 - At least one of PR110 or PR112 is required.

R020607 - At least one of AT302, AT306 or AT307 is required.

E (Exclusion) – только один из перечисленных элементов может присутствовать:

E0309 - Only one of PSD03 or PSD09 may be present.

E020607 - Only one of AT302, AT306 or AT307 may be present.

Семантические замечания


Стандарт может определять семантические правила для элементов сегмента. Эти замечания предназначены для лучшего понимания назначения элементов. Например, для сегмента PO1 существует такое семантическое замечание:

PO106 through PO125 provide for ten different product/service IDs per each item. For example: Case, Color, Drawing No., U.P.C. No., ISBN No., Model No., or SKU. (элементы, начиная с PO1-06 и заканчивая PO1-25 предоставляют 10 различных идентификаторов для каждого товара. Например: упаковка, цвет и т.д.).

Наконец, рассмотрим наш сегмент PO1 для примера, и посмотрим как стандарт X12 (версия 4010) описывает его элементы:

PO1*004005006*10*EA*15**BP*123456321~

Элемент	Описание	Тип данных	Значение
PO1-01	Assigned Identificator, присвоенный идентификатор	O AN 1/20	004004005
PO1-02	Quantity Ordered, количество заказанных экземпляров товара	C R 1/15	10
PO1-03	Unit/Basis Measurement Code, единица измерения количества товара	O ID (355) 2/2	EA = Each
PO1-04	Unit Price, цена единицы товара	C R 1/17	15
PO1-05	Basis Unit Price Code, код, идентифицирующий тип цены единицы товара	O ID (639) 2/2	-
PO1-06	Product/Service Id Qualifier, тип идентификатора товара/услуги	C ID (235) 2/2	BP = Buyer's Part Number
PO1-07	Product/Service Id, идентификатор товара/услуги	C AN 1/48	123456321

SYNTAX NOTES

C0302 - If PO103 is present, then PO102 is required.

C0504 - If PO105 is present, then PO104 is required.

P0607 - If either PO106 or PO107 is present, then the other is required.

Опциональность сегментов

Сегменты в документе имеют два типа опциональности:
M (mandatory) – обязательный сегмент. Обычно такие сегменты несут основную информацию в документе (без него документ или другие, зависимые сегменты, не могут быть поняты полностью и/или правильно). Если стандарт для данного документа определяет сегмент как обязательный, то он не может быть пропущен в документе. Примеры обязательных сегментов:
BEG*00*SA*ASNTESTORD**20060615~
Это (BEG) сегмент заголовка (см ниже, пункт Структура документа). Он содержит общую информацию документа (как «читать» сегменты – см. ниже):

назначение (00 – Original)

тип (SA - Stand-alone Order)

номер ордера (ASNTESTORD)

(20060615 – 6 Июня 2006)

Без этого сегмента нельзя было бы идентифицировать данный ордер.
PO1*001002003*10*EA*15**BP*123456411~
Это (PO1) сегмент деталей (см. ниже, пункт Структура документа). Он содержит базовые данные товара. Ордер заказа (PO) используется для заказа товара, и данные о товаре очевидным образом – основные данные этого документа, поэтому данный сегмент так же является обязательным.
O (optional) – необязательный, опциональный сегмент. Обычно это сегменты, содержащие второстепенную/вспомогательную информацию. Если стандарт определяет сегмент в документе как опциональный, то он может как присутствовать, так и отсутствовать, и при этом отсутствие опционального сегмента не будет являться ошибкой. Пример опционального сегмента:
PER*DC**TE*(123) 456-7890~
Это (PER) сегмент Administrative Communications Contact, т.е. «контактная информация». Он содержит следующую информацию (как «читать» сегменты – см. ниже):

контактное лицо по вопросам доставки (DC - Delivery Contact)

телефон (TE - Telephone)

собственно сам номер телефона - (123) 456-7890

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

Порядок следования сегментов

В документе сегменты идут друг за другом в порядке, определенном стандартом.

Повторение сегментов

Как вы могли заметить, в примере документа некоторые сегменты повторяются. Некоторые из них идут сразу друг за другом (DTM, PER), некоторые повторяются в составе групп (PO1/PID/ITA и N1/(N2)/N3/N4). Существует два типа «повторения» сегментов:
Возможность многократного использования сегмента.
В данном случае сегмент может повториться несколько раз, но при этом каждый сегмент имеет различное значение, т.е. несет разную информацию (сходную по смыслу, но разную по содержанию). Например, два DTM сегмента в примере документа определяют даты, но первый из них (DTM*002*20060625~) определяет дату поставки, а второй (DTM*010*20060618~) – дату погрузки. Аналогично PER сегменты – каждый определяет контактную информацию, при этом первый (PER*BD*DON SMITH~) определяет имя или название покупателя, а второй (PER*DC**TE*(123) 456-7890~) – телефон контактного лица по вопросам доставки. В документе для печати (который используется людьми) это могло бы выглядеть так:
Отдел продаж: +7 812 765 4321, Василий Смирнов
Отдел доставки: +7 812 123 4567, Иван Иванов
Склад: +7 812 321 7654, Петр Петров
Следует отметить, что часто уникальность сегмента заключается в использовании различных значений элемента (одного или иногда больше) идентификатора. В большинстве случаев в сегменте есть специальный элемент, который идентифицирует содержание сегмента. В сегменте DTM это, например, элемент DTM-01, в сегменте PER – PER-01.
Стандарт определяет максимально возможное количество таких повторений (max use).
Пример:
рис 4.
Циклическое повторение данных (Loops).
Циклическая группа сегментов (loop) – это набор связанных друг с другом сегментов, которые повторяются в EDI документе в определенной последовательности. Например, группа сегментов N1/N2/N3/N4 представляет информацию об адресе, причем N1 несет информацию об этом адресе, N3 – непосредственно сам адрес, и N4 – географическое расположение.
N1*ST*A1 STORES*93*0655~
N3*142 WAGON DRIVE~
N4*MIDDLETOWN*AR*72222~

N1*BT*A1 STORES*93*0655~
N3*75 CROSS ROAD~


N4*MIDDLETOWN*AR*72222~

Группа PO1/PID/ITA несет информацию о заказанном товаре, его цене и количестве (PO1), описание этого товара (PID) и скидке/наценке (ITA).

PO1*001002003*10*EA*15**BP*123456411~
PID*A****ADIDAS BLUE T-SHIRT~
ITA*A***CC***1000~

PO1*002003004*20*EA*20**BP*123456817~
PID*A****NIKE RED T-SHIRT~
ITA*A***CC***1500~

Такие циклические группы в свою очередь могут включать в себя другие циклические группы.

Пример:

рис 5.

X12 определяет два типа циклических повторений (loops) – связанные (Bounded) и несвязанные (Unbounded).

Несвязанные повторения имеют стартовый сегмент, который определяет всю группу. «Внутри» этой группы находятся остальные сегменты, их опциональность определяется, как указано выше, однако эти «дочерние» сегменты группы не могут существовать отдельно от стартового сегмента. В нашем примере PO1/PID/ITA сегменты PID и ITA не могут присутствовать в документе, если им не предшествует сегмент PO1. Может быть ситуация когда либо сегмент PID, либо сегмент ITA отсутствуют в группе (так как они опциональны), но ситуации когда PID и/или ITA присутствуют но нет сегмента PO1 быть не может. Это верно, даже если сама группа является опциональной. Следующая группа определяется стартовым сегментом, например N1/N2/N3/N4/N1/N2/N3/N4/N1/N2/N3/N4/… (стартовый сегмент - N1) или PO1/PID/ITA/PO1/PID/ITA/PO1/PID/ITA/PO1/PID/ITA… (стартовый сегмент – PO1) – тоесть, если в документе появляется стартовый сегмент, то он указывает на очередную группу.

Связанные повторения очень похожи на несвязанные, однако имеют отличие – такие группы сегментов ограничены «сверху» и «снизу» специальными сегментами – LS (Loop Start) и LE (Loop End). Такой подход используется стандартом, когда может быть невозможно определение начала и конца группы. В таких случаях начало и конец группы определяется не по стартовому сегменту собственно самой и следующей групп, а специальными сегментами LS и LE соответственно.

Как и в предыдущем случае, стандарт указывает максимальное количество повторений (Max Use) групп сегментов.

Сегмент

Сегмент (segment) – комбинация связанных элементов или составных данных, которые сгруппированы для предоставления полезной информации. Например, сегмент может содержать информацию о товаре, его цвете, весе, размере, объеме и т.д. Сегмент может присутствовать в документе единожды, или встречаться несколько раз.
рис 2.
В X12 на первом месте всегда идет уникальный идентификатор сегмента (tag), состоящий (как правило) из 2-3 букв/цифр.
Пример сегмента:
PO1*002003004*20*EA*20**BP*123456817~
Сегмент состоит из идентификатора (tag) и элементов, разделенных специальными символами (element separator) – в нашем примере это «звездочка» (asterisk) – «*». Заканчиваются сегменты другим символом (segment terminator) – в нашем примере тильдой «~». Следует отметить, что разделители элементов и сегментов могут отличаться от данного примера.
рис 3.
Стандарт определяет, в каком порядке идут элементы в сегменте.
В примере выше представлен сегмент стандарта X12 с именем PO1, который имеет значение Baseline Item Data (Базовые данные товара). Рассмотрим его подробнее.
В начале идет идентификатор сегмента (PO1), затем идут элементы сегмента:

Assigned Identificator (002003004, присвоенный идентификатор)

Quantity Ordered (20, количество заказанных экземпляров товара)

Unit/Basis Measurement Code (EA = Each, единица измерения количества товара)

Unit Price (20, стоимость товара)

элемент пропущен (!) (пропущен Basis Unit Price Code – код, идентифицирующий тип цены единицы товара)

Product/Service Id Qualifier (BP = Buyer's Part Number, тип идентификатора товара/услуги)

Product/Service Id (123456817, идентификатор товара/услуги)

Итак, данный сегмент «говорит» получателю – «в позиции 002003004 в нашем ордере заказа мы запрашиваем 20 единиц товара, который в нашей базе находится под идентификатором 123456817, по 20 долларов за единицу».

Структура EDI документа

Как уже было сказано выше, EDI документ можно представить в виде документа/документов, вложенных в конверты, которые имеют различное назначение.

Типы данных

В стандарте X12 определяются такие типы данных, которые может содержать элемент:
AN (Alpha-Numeric) - строка, которая может содержать буквы, цифры, знаки препинания. Это может быть произвольная строка, например имя товара или название улицы на которую нужно доставить товар, и т.д. Примеры: «БАТОН НАРЕЗНОЙ, 1-ГО СОРТА», «САНКТ-ПЕТЕРБУРГ».
Для этого типа данных так же накладывается ограничение на длину строки, например 1/20 – от 1 до 20 символов, 2/2 – ровно 2 символа и т.д.
R (Real) - дробное число. Данный тип данных используется для информации о цене, весе продукта, расстоянии, размере скидки и т.д. Примеры: 1.23; 75.99. Начиная с версии 4010 поддерживается экспоненциальная нотация.
N[X] (Number) – специальный формат числа. [X] определяет, сколько знаков справа надо «отступить» чтобы поставить запятую. Например, для типа данных N2 для обозначения числа 1,23 значением элемента будет 123, а для 10,5 – 1050 (тоесть чтобы получить нужное значение мы берем значение элемента и делим его на 102). N0 соответствует целому числу, тоесть его значение остается как есть.
ID (Identity) – идентификатор. Об этом типе данных следует рассказать подробнее. Простейший пример идентификаторов из реальной жизни – это единицы измерения, например «ММ» (миллиметр), «СМ» (сантиметр), «РУБ» (рубль) и т.д. В X12 все идентификаторы собраны в логические группы (классификаторы), и этим группам присвоены уникальные идентификаторы – номера. Классификатор состоит из нескольких значений, и каждое значение имеет свое уникальное имя (обычно, 2-3 буквы и цифры) и расшифровку (определение).
Примеры классификаторов – единицы веса, типы валют, коды стран.
Рассмотрим, например, классификатор (группу идентификаторов) номер 90

90 Measurement Unit Qualifier Единицы Измерения
TYPE=ID MIN=1 MAX=1 Тип – идентификатор, длина имени MIN = 1, MAX = 1
Code specifying the linear dimensional unit Код, определяющий единицу линейного размера
CODE	DEFINITION & EXPLANATION
C	Centimeters
E	Feet
N	Inches
X	Meters

Становится понятно, что если элемент сегмента у нас имеет тип ID из классификатора 90, то речь идет о длине.
И если значение этого элемента, например, «N», то длина определяется в дюймах (inches).

Особо отмечу, что если элемент имеет тип данных ID, то его значение может принадлежать только одному классификатору, определенному стандартом для этого элемента в данном сегменте. Иначе говоря, не может быть ситуации, когда элемент типа ID может быть единицей измерения массы (например, классификатор 188 Weight Unit Code) и в то же время – единицей измерения длины (например, классификатор 90 Measurement Unit Qualifier).

Так же часто в классификаторе существует специальное значение – «Z», «ZZ» или «ZZZ» в зависимости от ограничений по длине значения идентификатора. Это имя имеет расшифровку (определение) «Mutually Defined» (взаимно определенное), и используется для обозначения единиц, отсутствующих в стандарте для данного классификатора, о которых участники документооборота договорились заранее. Компании, которые обмениваются документами, когда встречают подобное значение идентификатора, в большинстве случаев знают, о чем идет речь – это могут быть «(33) попугая» или «(10) спичечных коробков».

Для этого типа данных так же накладывается ограничение на длину строки, например 3/3 – от 3 до 3 символов, или (проще говоря) 3 символа ровно. Данное ограничение исходит не от стандарта сегмента документа, а от типа используемого классификатора (если классификатор 90 определяет ограничение на длину значения как 1/1, то элемент-идентификатор который использует этот классификатор, так же будет иметь ограничение на длину 1/1).

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

DT (Date) – дата. Этот тип данных предназначен для хранения значения даты и имеет формат YYMMDD (начиная с версии 4010 – CCYYMMDD). Примеры: 20060625 (25 Июня 2006).

TM (Time) – время. Этот тип данных предназначен для хранения значения времени и имеет формат HHMM. Примеры: 1259 (12:59).Так же может включать секунды (опционально).

B (Binary) – бинарные данные, последовательность 8-ми битных байтов.

- композитный элемент. Это элемент, который содержит сразу несколько значений, разделенных специальным символом (этот символ указывается в сегменте ISA, элемент ISA-16). Примеры: 12345.67>12.55 (в данном примере разделителем является “>”). Элементы, из которых состоит композитный элемент, называются так же компонентами (component data element) или суб-элементами (sub-element).

Архитектура Web-служб FlexNet

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

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

business oriented - службы, реализующие бизнес-процессы;

system oriented - службы, реализующие системные функции (оценка производительности, мониторинг безопасности и т.д.);

device oriented - службы, обеспечивающие доступ к устройствам. Рынок Web-служб подразделен на две части:

Web services application - доступ к приложениям, размещенным в Сети;

middleware and tools - инфрастуктура, позволяющая пользователям создавать и выполнять собственные Web-приложения. С технологической точки зрения из четырех категорий Apriso выбрала в качестве предмета своей деятельности службы категорий business oriented и device oriented, а с точки зрения бизнеса она ориентирована на рынок инструментов и программного обеспечения промежуточного слоя.
Основной продукт Apriso, «гибкая сеть» FlexNet представляет собой решение, предназначенное для совместного производства и цепочки поставок, построенное на основе технологий XML-ориентированных Web-служб, входящих в Microsoft .Net. В число основных использованных средств входят Microsoft BizTalk Server, управляющий интерфейсом между приложениями, который построен на основе слабо связанных сообщений, а также Crystal Reports, входящий в состав Visual Studio .Net, служит средством для генерации графических отчетов и запросов, позволяющих обращаться к любому типу устройств через Internet. Кроме того, в FlexNet используются операционные системы Windows 2000 Server, Advanced Server и Datacenter Server, .Net Framework, Visual Studio .Net, язык программирования C#, СУБД SQL Server 2000 и компонентная объектная модель Component Object Model (COM).
Перечислим основные компоненты, из которых состоит архитектура FlexNet (рис. 1).

Рис. 1. Архитектура Apriso FlexNet

FlexNet Real-Time Enterprise Database. Все приложения, работающие в среде FlexNet, используют реляционные СУБД Microsoft SQL Server или Oracle, которые поддерживают операционные данные о работе предприятия. Корпоративная база данных состоит более чем 900 таблиц, она может содержать весь набор данных о продукции, логистике, контролю качества, управлению процессами. СУБД может работать автономно или синхронно совместно с базами данных приложений ERP, CRM, PLM или SCM. База данных может быть единственной консолидированной или распределенной между несколькими площадками со всеми необходимыми механизмами репликации и управления.

Data Access Layer. Уровень доступа, основанный на XML, образует платформу для доступа к данным, обеспечивающую совместимость и масштабируемость.

Business Services Tier. Службы представляют собой допускающие повторное использование строительные блоки, из которых могут быть "собраны" компонентные приложения. Apriso разработала основной набор XML-ориентированных Web-служб, который обеспечивает взаимодействие пользователей в процессе производства и распределения продукции.

Web Services Wrapper. Оболочка, которая преобразует приложения в XML-ориентированные Web-службы. Visual Studio .Net автоматически создает необходимые интерфейсы для объектов XML и объектов протокола SOAP, необходимые для превращения и сборки повторно используемых компонентов в XML-службы, что позволяет разработчикам сосредоточится на бизнес-логике приложений.

ASP.NET User Interface Framework. Платформа .Nеt Compact Framework обеспечивает взаимодействие с мобильными устройствами.

Web Forms. Одна из основных технологий Visual Studio .Net, которая позволяет разрабатывать кросс-платформенные и независимые от типа браузера Web-приложения, используя те же самые приемы, что и для приложений, предназначенных для настольных компьютеров.

Web Services Applications. Эти приложения доступны для пользователей с применением персональных компьютеров или мобильных устройств.

Machine Integrator. Интеграционная машина, представляющая собой систему распределения данных.

Workflow Manager. Выполняет функции распределения задач.

XML Manager. Интеграция приложений ERP, CRM, PLM и SCM средствами Microsoft BizTalk Server.

Enterprise Integration. Прозрачная для пользователей интеграция SCP, ERP, PLM и CRM. Утверждается, что FlexNet обеспечивает сертифицированный интерфейс с системами SAP R/3, mySAP.com и Oracle e-Business Suite.


Кроме того, есть возможность интегрировать приложения с использованием стандартов ANSI/ISA 95.00, ebXML и RosettaNet.

Даже поверхностное сравнение решений архитектуры, ориентированной на службы от компании Apriso с тем, что предлагают адепты Java, показывает: перед нами корпоративная интерпретация .Net, которая воплотила в себе генетические черты программных продуктов Microsoft со всеми их достоинствами и недостатками. n

Шина ESB, предложенная Sonic, один из важнейших компонентов SOA, построена на основе ориентированной на Java системы обмена сообщениями JMS. Поэтому сегодня архитектура SOA почти однозначно ассоциируется с миром Java и особенно с платформой J2EE. Однако сама по себе идея объединения приложений средствами Web-служб не связана с какой-то единственной технологией. Существуют альтернативные, близкие по функциональности решения, построенные на базе .Net. В наиболее полном виде решение, аналогичное SOA, в основу которого положена философия Web-служб можно найти у компании Apriso.

В последние месяцы архитектура

Apriso, материализующая архитектуру, альтернативную SOA, в России не слишком известна. Деятельность компании была рассчитана на поставку приложений только для крупных заказчиков; за десять лет существования набралось всего 140 клиентов, но среди них General Motors, Honeywell, Matsushita Avionics, Lockheed, British American Tabacco и им подобные. Генезис нового названия Apriso обнаруживается в испанском слове aprisa, которое переводится как нечто не только «быстрое», и к тому же «твердое» или «упорное». Случившееся переименование не самоцель; вместе с ним компания произвела то, что называют ребрендингом. Она изменила и свой статус: если прежде она была известна как поставщик штучных решений CRM и SCM, то в новом качестве Apriso предложила FlexNet — оригинальный инструментарий интеграции приложений, который должен стать в большей мере массовым и расширить круг заказчиков компании.
FlexNet (вторая часть имени явно указывает на родственность .Net) построен на фундаменте корпоративной философии Bottom-out. Основные положения этой философии изложены в отнюдь не шуточном документе, где излагаются основы технической стратегии Bottom-out Enterprise Software. Однако озаглавлен он несерьезно: «Если бы в футбол играли так, как делают бизнес». Суть образного сравнения такова: попробуйте представить себе, что футболисты лишены индивидуальной личной инициативы и вместо моментальной реакции на изменения игровой ситуации следуют строго прописанным правилам. Нет слов, абсурд, но, как ни странно, в не менее сложных, чем любая игра, условиях бизнеса XXI века корпоративные информационные системы строятся по тем же принципам, что и несколько десятилетий назад.
Для того чтобы отличить свой подход к построению систем, в Apriso классические системы называют спроектированными «сверху вниз» (Top-Down), развивая при этом альтернативный подход Bottom-Out, что можно перевести как «от основания». Если отбросить метафоры и перевести маркетинговый язык в термины кибернетики, то надо сказать, что в Apriso осознали невозможность строить сложные детерминированные системы на принципах программного управления и ищут пути создания систем с элементами самоуправления.
Иного пути к «предприятию, работающему в режиме реального времени» (Real Time Enterprise), не дано. В IBM для самоуправляемых систем предложен термин autonomic computing, другие обозначают их словосочетанием autonomous systems, но как бы не называли разные фирменные подходы, их роднит необходимость в переходе от интуитивно обоснованных методов построения систем к системам, построенным по хорошо известным кибернетическим принципам. Internet и другие коммуникационные технологии изменили окружающую среду по причине исключительно возросшей скорости обмена данными. На внешние воздействия теперь требуется реагировать в соответствии с этими скоростями, т. е. в режиме реального времени.

В официальных документах Apriso большое внимание уделяется экономическому обоснованию предлагаемых продуктов и решений. Для обозначения новой экономики существует масса вариаций на тему e-business. Есть и другие, одна из них — The Execution Economy, т. е. «экономика исполнения» или «исполнительная экономика». Исполнительная в том смысле, что предполагает не строгое следование предписанной программе, а оперативное исполнение или отработку реакций на внешние воздействия (примерно то же самое означает еще один растиражированный термин — «по требованию»). Реализовать обработку по требованию (On Demand) можно на разных уровнях, на программном, на аппаратном, но самое критическое требование — это требование со стороны потребителя: предприятие должно выпускать то, что требует потребитель. Другими словами, не отдельные системы и подсистемы должны быть построены On Demand, а все предприятие в целом.

Есть две полярные экономические модели — push, навязывающая потребителю производимые товары и услуги, хорошо знакомая по временам социализма, и ее альтернатива pull, полностью подчиненная потребителю. Ни та, ни другая модель в чистом виде существовать не могут; однако для эффективной работы в идеале функционирование предприятия должно приближаться ко второму варианту. Для того чтобы добиться этого, вся информационная система должна функционировать On Demand, от самого основания, Bottom-Out.

Методы анализа

В настоящее время для определения эффективности ИТ-инвестиций предлагается ряд методик, которые можно группировать следующим образом [1, 2]: традиционные финансовые методики (Return оn Investment, Total Cost of Ownership, Economic Value Added); вероятностные методы (Real Options Valuation, Applied Information Economics); инструменты качественного анализа (Balanced Scorecard, Information Economics).
Достоинство финансовых методов — их база, классическая теория определения экономической эффективности инвестиций. Данные методы используют общепринятые в финансовой сфере критерии (чистая текущая стоимость, внутренняя норма прибыли и др.), что позволяет ИТ-руководителям находить общий язык с финансовыми директорами. Главный недостаток — в ограниченности применения таких методов: они оперируют понятиями притока и оттока денежных средств, требующими конкретики и точности. Определить отток денежных средств (затраты на ИТ-проект) можно по суммам, указанным в договорах с интеграторами и поставщиками. Проблемы возникают при попытке определения притока денежных средств. Проиллюстрировать ситуацию можно на примере внедрения ИТ в сфере проектирования и подготовки производства (ППП) машиностроительных предприятий.
Традиционно экономический эффект от мероприятий по совершенствованию сферы ППП выражается в ускорении подготовки производства и снижении затрат на ее осуществление. На ранних этапах внедрения ИТ в сфере ППП (период 70-х — 80-х годов) основным источником прибыли являлась автоматизация рутинных операций по созданию и корректировке конструкторской документации. Сегодня, даже в случае обнаружения таких резервов, экономия может оказаться незначительной: заработная плата конструкторов (основная составляющая такого рода экономии) и других специалистов на отечественных промышленных предприятиях по-прежнему низка. Внедрение современных многофункциональных систем проектирования часто приводит к удорожанию некоторых процессов ППП за счет высоких затрат на приобретение современного программного и технического обеспечения, затрат на обучение специалистов, потребности в проведении физического прототипирования спроектированного изделия.
Экономический эффект от снижения затрат, который ранее вычисляли по снижению затрат на процессы ППП, оказывается несущественным.

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

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

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

Вероятностные методы можно применить для оценки другого фактора эффективности ИТ в сфере ППП — вероятности своевременного и качественного выполнения проекта по разработке изделия.


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

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

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

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

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

Оценка эффективности ИТ-инвестиций

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

Требования к методикам

Обычно на промышленных предприятиях применяют или адаптируют методические рекомендации по оценке эффективности инвестиционных проектов, утвержденные государственными органами. Однако традиционные финансовые подходы не всегда приемлемы, поэтому анализ часто принимает неформальный характер; руководители ИТ-отделов полагаются на собственный опыт, либо на оценки «экспертов». Рассмотрим основные требования, предъявляемые специалистами-практиками к существующим методикам проведения анализа ИТ-инвестиций.
Ряд традиционных требований сформулирован в [3] (данные требования были предъявлены к АСУ, однако их действие можно расширить и на системы других видов, в частности, используемые в сфере ППП):

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

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

метод должен допускать только однозначное толкование и позволять с единых принципиальных позиций подходить к разным классам систем управления, в разных отраслях народного хозяйства и на разных этапах разработки, внедрения и функционирования систем. Правомерность последнего требования иллюстрирует метод определения совокупной стоимости владения (Total Cost of Ownership, TCO). Ключевым моментом при использовании этого метода является сравнение частных показателей ТСО предприятия с показателями ТСО других компаний аналогичного профиля. Отсутствие единых принципиальных позиций в методике определения и анализа ТСО на различных предприятиях (например, изменение состава анализируемых статей расходов на содержание ИТ-инфраструктуры) делает его применение бессмысленным.
Важное требование вытекает из замечаний, изложенных в [4] о неправомерных сравнениях, к которым прибегают ИТ-руководители в ходе анализа эффективности инвестиций.
Наиболее часто встречающимся примером является сравнение компьютеризированного труда с идентичной работой, выполняемой вручную. Поэтому методика проведения анализа ИТ-инвестиций должна иметь сравнительный характер, причем в следующих двух аспектах:

сопоставление внедряемой технологии должно проводиться с уже существующими на предприятии системами и технологиями с целью определения степени оптимизации процессов;

сопоставление должно проводиться с вариантами, аналогичными по функциональности и отраслевой принадлежности, представленными на рынке и внедренными на предприятиях-конкурентах, что объясняется необходимостью сравнивать собственные решения с решениями конкурентов. Многие авторы [3, 5, 6] поддерживают другое очевидное требование: методика анализа должна позволять выделять из общего повышения эффективности бизнеса ту часть, которая связана с внедрением новой информационной системы. Однако здесь важно сделать акцент на следующем: нередко внедрение ИТ сопровождается реинжинирингом бизнес-процессов. Так, при информатизации процессов ППП редко ограничиваются установкой дополнительных компьютеров и новой системы CAD/CAE; уже давно признана необходимость проведения в ходе таких проектов организационных и культурных изменений, например, внедрение принципа сквозного параллельного проектирования. Поэтому, рассчитывая эффект от реализации ИТ-проекта, мы определяем эффективность внедрения не только новой системы CAD/CAE, но и новых принципов работы, что далеко не одно и то же: первое предполагает автоматизацию или механизацию (приводит к экономии ресурсов), второе — организационную инновацию (приводит к получению нового знания, опыта). Следовательно, методика анализа должна обладать свойством системности, позволяя выделять из общего повышения эффективности бизнеса часть, связанную с реализацией мероприятий конкретного ИТ-проекта как единого целого, что определяет получение синергетического эффекта.

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


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

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

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

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

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


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

I этап. Анализ и формулировка тенденций и перспективных направлений развития отрасти.

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

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

IV этап. Составление перспективного плана ИТ-проектов предприятия в сфере ППП, формулировка цели для каждого из них.

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

Новый ландшафт систем автоматизации

27.06.2003
Наряду с хорошо известными MRP, ERP и им подобными ландшафт средств автоматизации относительно недавно пополнился множеством непривычных аббревиатур. Среди них стали весьма популярны PLM, EAM, SCP, MES, которые весьма активно вытесняют привычные сокращения, образуя совершенно новую синтетическую сущность, которую аналитики все чаще называют ERP II. Попытаемся разобраться в сущности этих понятий и их взаимосвязи, показав образованный ими новый ландшафт интегрированной системы управления, принципиально отличающийся от привычного ландшафта ERP. Прежде вспомним историю систем ERP-систем. Они были ориентированы на поддержку функционального управления предприятием — на автоматизацию отдельных процессов производства, финансов, сбыта, продаж, закупок и и.п. В первую очередь, подобные системы были предназначены для решения главной задачи данного функционального блока — планирования производства. Это предполагает, в частности, расчет потребности в материалах (MRP), затем расчет выполнимости производственного плана (CRP), ведение счетов для финансового блока, и так далее. При этом преимущественно предполагалось, что бизнес построен на производстве как на основе, а все остальное в значительной степени является обслуживающими процессами, из которых наиважнейшим является управление финансами. В момент возникновения программных продуктов категории MRP II, что соответствует началу 90-х годов, это предположение было неверно лишь для очень крупных компаний, где логистическое обеспечение продаж давно стало самостоятельной задачей. Однако ввиду уникальности процессов, ныне известных как управление логистическими цепочками, задача эта решалась при помощи столь же уникальных заказных продуктов; многие из них работают до сих пор. Обмен информацией (так называемые «заказы») между функциональными блоками осуществлялся на основе документов («первичка»), что полностью соответствует стандартной отечественной практике. Соответственно планирование выполнялось, а исполнение реализовывалось только внутри одного блока, хотя бы и очень большого (например, MRP II).
При этом существенную проблему представляла, да и представляет до нынешнего дня, интеграция подобных «документоориентированных» систем в единую информационно-аналитическую систему. Одной из существенных причин таких проблем является необходимость поддержки разнообразного документооборота для отдельных типов товарно-материальных ценностей в системах, ориентированных на функциональное управление, особенно в ситуациях, когда необходима «сквозная» поддержка определенных процессов или аналитических «срезов».

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

Целевая интеграция логистических, производственных и других функциональных систем, включая финансы и управление персоналом, сначала получила название COMMS (CSRP), а позднее была названа SCM («управление логистическими цепочками»), под которым ныне и получила широкую известность (рис. 1). Любопытно, что разделение этих названий связано с разделением непосредственного и косвенного производителя («брэнда»), так как первые были ориентированы практически только на заказное производство (единичное, в стандартной российской терминологии), а вторые — на любой тип производства, в том числе и на массовые брэнды.


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

Рис. 1. Логистическая цепочка

Принципиально важно отличать управление логистическими цепочками, ориентированное на полный сбытовой цикл, и действия, ориентированные на управление ячейками такого цикла. Очень показательный пример — производитель-субподрядчик в составе брэнда. Такого рода логистический менеджмент получил название «взаимодействующий бизнес» (collaborative business), а соответствующая система планирования — collaborative planning, и, наконец, соответствующая такого рода организации бизнеса программная система поддержки логистики — PRM. Типы транзакций в обоих случаях различны. Если в первом управляется «полная транзакция», включающая все операции логистической системы, то во втором — «частичная», но принципиально являющаяся элементом транзакции управляющей «большой» логистической цепочкой компании.

Существенное влияние на развитие процесса процессной интеграции информационных систем оказало также развитие принципов менеджмента качества, а именно принципов управления «жизненным циклом изделий» (рис. 2).

Рис. 2. Жизненный цикл изделия в системе качества

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


Следующая задача — это управление активами. Функциональность для управления активами получила название EAM. Задача, решаемая в рамках транзакции «использования актива» в чем-то аналогична транзакции «жизненного цикла», и может быть названа «жизненным циклом актива». Системы PLM и EAM тесно пересекаются, скажем, на уровне цеха, где система управления цеховыми заданиями (или диспетчирования, MES) используя для производства определенной заказом клиента продукции конкретное оборудование, оснастку или инструмент, одновременно дает EAM основания для его амортизации или обслуживания в соответствии по мере использования. EAM, в свою очередь, предоставляет MES график ремонтов или обслуживания в соответствии с сервисным листом. Взаимодействие MES с PLM и SCP достаточно очевидно и хорошо известно. Заметим, что в случае единичного производства, SCP вынуждена для точного определения времени завершения заказа и планирования последующих логистических операций обращаться именно к MES, CRP в этом случае принципиально недостаточно, и в этом случае она, если и применяется, то только для чернового планирования или просчета месячных прогнозов.

Реализация и PLM, и EAM в стандартных документоориентированных системах крайне сложна, так как необходима сложная интеграция практически всех функциональных подсистем в части даже не типа продуктов, а партии или даже единичного продукта, относящегося к конкретному клиентскому заказу. Поддержка такого процесса требует существенной модификации учетных процедур и в «ручном» варианте практически нереализуема, а в стандартной ERP системе крайне затруднена. Видимо, именно поэтому в отечественной практике хотя и существовал термин «единичное производство», практически точно соответствующий западному «заказному» в современной трактовке, однако учетные процедуры по нему, включая методики расчета себестоимости, нигде не были прописаны. Термин «единичное» неудачен: не только возможна, но и весьма распространена ситуация «единичной» или «уникальной партии».


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

В свою очередь, инструментарий ERP II предназначен для поддержки интегрированной логистической системы, или обособленного элемента такой системы (рис. 1). Типичным покупателем такой системы является компания, продукция которой попадает, по крайней мере, под одно из определений: малое время стадии «нахождение на рынке» — менее одного года; заказной характер производства или закупок; очень высокая дифференциация и высокая чувствительность к «движениям рынка» (малое время реакции логистической системы на изменение потребительских предпочтений).

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

Рис. 3. Интеграция стороннего производителя

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

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


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

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

Рис. 4. Транзакционные расширения ERP

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

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

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


Это разрушает иллюзию «универсальности» ERP-системы. Более того, PLM- система должна быть ориентирована на управление жизненным циклом конкретного типа продукции, а не дискретной продукцией вообще, либо должна также подвергаться глубокой настройке. Иначе, в рамках MRP II предприятия одного типа и вида производства имели бы идентичную функциональность и систему планирования. Но с точки зрения управления жизненным циклом они существенно различаются. Управление активами, образующими ИТ-инфраструктуру подразделения крупной компании и дачного поселка, хотя и похожи функционально, но принципиально отличаются с точки зрения EAM — предоставляемые ими услуги и их оценка связаны с совершенно различными процессами.

Опыт внедрения ERP в России полностью подтверждает эту практику, и более того, большинство неудач связано как раз с принципиальными ошибками при выборе «вертикально чувствительного» программного обеспечения, как например, попытки внедрить на непрерывном производстве MRP II. Проблемы, даже не с автоматизацией, а просто с бюджетированием холдингов также связаны с транзакционным характером финансовых и логистических операций в рамках холдинга. Бюджетирование же транзакционной системы, хотя и сходно по функциональной структуре с документоориентированной, но принципиально отличается по процессам и последовательности действий. К сожалению, на отечественном рынке практически не представлены наиболее современные продукты большинства типов транзакционных систем, а в отечественных системах поддержка транзакций, как правило, принципиально невозможна.

Архитектура Web-OLAP

Для архитектуры, реализующей идею Web-OLAP, недостаточно простой реализации клиент/серверной модели. Появляются новые технологии обработки. Оценка предлагаемых продуктов зависит не только от анализируемого объема данных, но и от возможности масштабирования по количеству пользователей.
Большинство Web-OLAP приложений используют общую архитектуру, в которой клиентский браузер взаимодействует с HTTP-сервером, пересылающим HTML-страницы. Но помимо этого предоставляется еще и промежуточное (связующее) ПО, хранящееся на сервере. Такой компонент может напрямую связываться с Web-браузером или взаимодействовать с HTTP-сервером, который затем возвращает браузеру HTML-страницы с дополнительными данным.

Web-OLAP компонент промежуточного уровня выполняет набор функций, которые не может обеспечить HTML, а именно:

взаимодействие с базой данных, где находится Хранилище;

хранение состояний (предыдущих транзакций базы данных);

вычисление и буферизация данных, возвращаемых на клиент. Последним компонентом этой архитектуры является база данных. Web-браузер не соединяется с ней напрямую: за это отвечает связующее звено. Таким образом, ограниченные возможности HTML наряду с лимитированным доступом клиентской машины на сервер обеспечивают достаточную безопасность при извлечении данных из реляционной базы.
В большинстве случаев (хотя это и не обязательно) связующее ПО хранится на том же компьютере, что и HTTP-сервер. Оно должно взаимодействовать с базой, где находится Хранилище. При этом необходимо обеспечить права пользователей и сетевой доступ так, чтобы промежуточный компонент мог извлекать данные, необходимые для OLAP-приложения. Связующее ПО – потенциально критический элемент в Web-OLAP архитектуре. Поэтому он должен быть спроектирован оптимально, чтобы не понижать общую производительность системы. При неправильном конфигурировании, сложная программа промежуточного уровня может очень медленно выполнять запросы пользователей.
Размещение промежуточного ПО между клиентской частью и базой данных снижает издержки, связанные с перемещением данных и потенциально может повысить производительность системы.
Такой подход предотвращает разрастание объема ХД. Централизованное хранение информации, доступной для всех пользователей с помощью OLAP-инструментов, устраняет риск работы с устаревшими данными, так как все пользователи будут обращаться только к тем элементам, которые находятся в центральном Хранилище.

HTML-решения

Для реализации OLAP-функциональности в Web-браузере используется только HTML.
Простым примером такого решения является OLAP-инструмент, позволяющий пользователю выполнять предопределенные OLAP-запросы или отчеты из браузера; другой функциональности при этом не предусматривается.
В этом случае для получения данных из автономных OLAP-машин используются планировщики, формирующие статические HTML-отчеты по HTML-шаблонам. Шаблоны создаются таким образом, чтобы все отчеты имели согласованный вид. Отчеты обрабатываются и передаются в браузер с помощью Web-сервера. Статические отчеты характеризуются хорошей переносимостью, быстро доставляются в браузер, при этом взаимодействия пользователя с браузером практически не происходит. В некоторых случаях имитируется переход по измерениям путем навигации по отчету. Планировщик может создать набор отчетов, связанных между собою гиперссылками. К примеру, пользователь, щелкнув по ссылке под названием «Третий квартал», переедет к другому отчету, содержащему данные за июль, август и сентябрь.
Существует и другой подход, чаще используемый: OLAP-сервер наполняет HTML-шаблон данными в оперативном режиме, то есть по мере поступления запроса пользователя через браузер. В этом случае на Web-сервере хранятся только шаблоны отчетов и метаданные. Эти метаданные содержат информацию, необходимую Web-серверу для передачи тех или иных данных в HTML-файл перед тем, как отправить его в браузер.
Метаданные могут храниться на сервере в двух форматах: в виде обычных HTML-тэгов в шаблонах на сервере (в HTML-файле) или в двоичном формате, например как поля в базе данных.
HTML-шаблоны также представимы в одном из двух форматов. Если для создания шаблонов используется готовый редактор, то они хранятся в обычных гипертекстовых файлах на Web-сервере. Пользователь может щелкнуть в браузере по ссылке с названием отчета и HTML-шаблона. Некоторые поставщики предлагают инструментальные Web-средства для создания и хранения метаданных шаблонов вместе с метаданными отчетов в двоичном формате.
В таком случае и отчет, и шаблон могут быть созданы в оперативном режиме с помощью специальных процессов Web-сервера.

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

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


Совместное использование HTML и Java-апплетов позволяет создать отличное Web-OLAP решение. В этом случае HTML применяется для отображения меню и выполнения простых интерфейсных функций, а с помощью Java-апплетов обеспечиваются более сложные компоненты интерфейса программы, а также согласованное отображение диаграмм, графиков и таблиц. В таких приложениях чаще всего реализованы функции агрегирования и детализации, а также вращения (pivoting) данных. За счет широких графических возможностей Java по сравнению с HTML, можно представлять данные в виде диаграмм и изменять их в интерактивном режиме.


Одно из самых слабых мест HTML – невозможность хранить состояния. Предлагаемый вариант решения проблемы – использование CGI (Common Gateway Interface – общий шлюзовой интерфейс) или других Web API (Application Programming Interface - интерфейс прикладного программирования) для реализации связующего ПО (middleware). С помощью этого метода можно обеспечить хранение состояний, а также буферизацию строк, возвращаемых на клиент, и выполнение некоторых вычислений над передаваемыми данными.
В случае использования такой архитектуры переносимость для клиентских платформ обеспечивается за счет использования HTML в качестве интерфейса. Однако в зависимости от того, как реализовано приложение Web-сервера, проект может также переноситься с одной серверной платформы на другую. Это, в частности, касается CGI-приложений, обладающих высокой переносимостью. О большинстве других Web API этого сказать нельзя. Например, серверное приложение, разработанное с использованием API Microsoft Internet Information Server (ISAPI) вероятнее всего будет работать только на Internet Information Server.
Однако и в этом случае использование только HTML налагает ограничения на интерфейс. Правильное отображение графиков и отчетов будет затруднено. Эта проблема решается с помощью Java-апплетов, которые обладают большими возможностями по управлению выводом информации на монитор.

Internet/Intranet OLAP

Сегодня многие компании применяют intranet-технологии для развертывания Хранилищ данных и предоставления OLAP-функций в масштабе всего предприятия, а затем переходят и к технологиям extranet, чтобы обеспечить своих партнеров (поставщиков, оптовых и розничных продавцов, представителей филиалов) защищенным доступом к Хранилищу и OLAP-средствам. Такой способ расширенной поддержки принятия решений позволяет сотрудничающим организациям совместно использовать информационные ресурсы и находить новые возможности развития бизнеса.
Однако совместный доступ требует определенного уровня конфиденциальности и защищенности информации. Поэтому, прежде чем внедрить систему поддержки принятия решений в extranet, необходимо четко определить информационные и аналитические потребности конкретных пользователей. Бизнес партнерам, нуждающимся в поддержке принятия тактических решений, не требуются средства стратегического анализа и соответствующая информация. Так для определения объема поставок на следующий месяц поставщикам необходимы только данные о продажах за последний период, а сведения о долговременных продажах или о планируемых доходах им совсем не нужны. Внешним бизнес-партнерам (например менеджерам-координаторам) не требуются мощные инструменты нерегламентируемого анализа, так необходимые для стратегического принятия решений.
Итак, Web – это очень продуктивный способ передачи информации всем участникам процесса принятия решений. Применяя технологию Web-OLAP наряду с агентами оперативной доставки данных на сервер (push-technology), можно предоставить менеджерам приоритетную информацию, связанную с определенными бизнес-правилами.
Web помогает решать сложные задачи, возникающие при распространении программного обеспечения в нецентрализованных средах, встречающихся, как правило, в большинстве компаний. С помощью Web-браузеров осуществляется не зависимая от платформы поддержка интерактивной OLAP-отчетности в международных организациях, имеющих поставщиков по всему миру. Обучение сотрудников OLAP-анализу сводится к минимуму за счет использования хорошо знакомых Internet-функций и методов навигации (например переходов по гиперссылкам для углубления в данные).

Java или Active X

Следующий подход предполагает использование Java- или ActiveX-компонентов для минимизации взаимодействия между браузером и Web-сервером, а также расширения возможностей пользователя по работе с данными за счет более качественного интерфейса. Существует два способа применения этих компонентов.
В первом случае Web-сервер заполняет двоичный файл данными для отчетов, и интерфейсные компоненты посылаются в браузер вместе с ответным HTML-файлом. На клиенте одно из свойств управляющего элемента (ActiveX или Java) задает для браузера название соответствующего файла данных. Браузер скачивает этот файл, а компонент загружает данные. Таким образом, компоненты обеспечивают выполнение таких OLAP-функций, как агрегирование, детализация и вращение с помощью удобного интерфейса, без обращения к серверу. Поскольку передача данных между клиентом и сервером осуществляется в двоичном формате, такой подход можно считать более безопасным.
Во втором случае, интерфейсный компонент напрямую соединяется с сервером, который в интерактивном режиме передает данные на клиент по мере поступления запросов пользователей. В этом случае интерфейсный компонент запрашивает данные с Web-сервера, открывая HTTP-поток. Затем, получив результаты с сервера, он анализирует полученную информацию и предает данные на объект для отображения.
Кроме того, компоненты очень удобно использовать вместе со связующим ПО – приложением, которое осуществляет буферизацию данных и выполняет вычисления и агрегирование перед тем, как передавать данные на клиент. Потенциально, за счет выполнения этих действий не на клиенте, а на сервере общая производительность Web-OLAP приложения может повыситься. Именно такое решение дает самый широкий набор OLAP-функций.

OLAP-средства и Web-технологии

Дата: Май 2003 года
Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab Успешно развивающиеся технологии Хранилищ данных (ХД) и средств Business Intelligence (BI) – весьма полезные инструменты поддержки современного бизнеса. Однако большинству традиционных BI-приложений свойственны некоторые ограничения. Технология, на основе которой они реализуются, была разработана для анализа небольших выборок данных. Со временем круг пользователей расширялся, но ориентация на небольшие объемы данных при этом сохранялась. Наконец, появились технологии, предназначенные для обработки постоянно растущих огромных объемов данных, содержащихся в Хранилищах.
Такие технологии, как многомерный OLAP, реляционный OLAP и гибридный HOLAP, обеспечивают новые подходы к анализу больших баз данных. С другой стороны, они накладывают ограничения на количество пользователей. Для того, чтобы снять эти ограничения, следующее поколение BI-средств использует аналитические методы в сочетании с технологией Internet/Intranet. Если раньше крупномасштабный BI-проект подразумевал сотни пользователей, то теперь поддержка нескольких тысяч человек считается обычной, а в будущем предполагается обеспечивать сотни тысяч и более.
Динамические технологии, появление которых стало возможно в результате развития «всемирной паутины» (World Wide Web), представляют собой прекрасную альтернативу традиционным клиент/серверным OLAP-методам. За последнее время появился целый ряд OLAP-средств (их называют Web-OLAP или WOLAP), оснащенных Web-возможностями. Они выполняют аналитические функции, такие как агрегирование и детализация (drill-up и drill-down), а также обеспечивают высокую производительность в сочетании со всеми преимуществами, которые дает Web-приложение.
С такими приложениями значительно облегчается задача установки, конфигурирования и развертывания. Web-приложение выполняется на сервере, и поэтому на клиентской машине нужен только Web-браузер и подключение к Intranet/Internet. Подобная стратегия развертывания особенно удобна для администраторов Хранилищ данных, которым часто приходится работать с широким контингентом удаленных пользователей (например, с продавцами или служащими отделов, расположенных в удаленных офисах), что очень не просто при использовании традиционной клиент/серверной архитектуры.

Использование Web-технологий влияет и на стоимость BI-приложений:

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

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

Подходы к реализации Web-OLAP

На сегодняшний день реализовано множество различных Web-OLAP решений, в том числе на основе технологий HTML (DHTML), Java, ActiveX, а также комбинации выше названных.

Перечислим основные типы продуктов:

HTML(DHTML)-решения.

HTML с расширениями – CGI, связующее ПО.

HTML с использованием Java-апплетов.

Java или ActiveX-компоненты.

Предпочтения пользователей

В ходе опроса, который проводился Survey.com, компанией, занимающейся маркетинговыми исследованиями в области Web-технологий, пользователям Web OLAP-систем был задан вопрос, касающийся их предпочтений в отношении архитектуры (Java, ActiveX, DHTML и т.п.). С учетом места и значимости Web-а, ожидалось, что эти предпочтения будут достаточно четкими. Но на деле это предположение себя не оправдало. Треть респондентов заявила, что четкого мнения на этот счет не имеет, а тех, кто твердо придерживается той или иной архитектуры оказалось намного меньше. Среди них наибольшей популярностью пользуется Java, это объясняется тем, что в опросе участвовали пользователи фирмы Oracle, из которых 37% предпочитают именно такую архитектуру. И, наоборот, заказчики компании Brio одобряют технологию своего поставщика, предпочитая встраиваемые модули (plug-in approach). Клиенты Cognos придерживаются использования только HTML, именно эта архитектура заложена в PowerPlay. Некоторые участники опроса отметили свое желание работать с ActiveX. В целом, сложилось впечатление, что большинство респондентов поддерживают ту технологию, которая реализуется их поставщиками. Это связано либо с выбором продукта в зависимости от его Web-архитектуры (что маловероятно), либо с «подготовкой», которую провел разработчик, поставляющий приложения. Удивительно то, что лишь немногие пользователи высказались за использование XML или XSL в качестве наиболее удачной Web архитектуры, и практически никто не отметил DHTML (Динамический язык HTML), несмотря на то, что для большинства поставщиков OLAP-инструментов рассматривают эти языки как основные средства реализации.
В целом пользователи довольны большинством лидирующих OLAP-продуктов, однако многие вчерашние «звезды» рынка уже поблекли. Мало нашлось активных пользователей известных продуктов, таких как Gentia, Holos, Pilot, SAP BW и SAS MDDB, да и те немногие, кто ими пользуется, меньше удовлетворены результатами, чем все опрошенные в среднем.

Оперативная аналитическая обработка много лет

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

Удобство использования.

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

  WebIntelligence делает аналитические возможности доступными для различных категорий пользователей. Новичок может воспользоваться функцией пошагового создания отчетов и автоматического («по щелчку») анализа данных. Для опытного пользователя обеспечен широкий набор BI-средств, в том числе создание сложных отчетов, выполнение вычислений, фильтрация, детализация и агрегирование (drill through).

Архитектура.

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

Интерактивность.

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

WEBINTELLICENCE обеспечивает следующие возможности:

форматирование и печать отчетов в режиме визуального проектирования ( What You See Is What You Get - WYSIWYG);

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

возможности детализации данных (drill down) в интерактивном режиме.


Поддержка всех возможностей (выборка данных с заданными измерениями и значениями (slice and dice), «углубление» в данные, вложенные перекрестные таблицы, вычисление, включение/отключение отображения строк, столбцов и графиков; фильтры, сортировка) для просмотра, исследования, отчетности и публикации OLAP-данных в интерактивном режиме.

Функциональность.

Основные функциональные возможности достигаются за счет следующих средств:

MicroStrategy 7i OLAP Services – интерфейс к продуктам «третьих» фирм;

технология Intelligent Cube (работающая под MicroStrategy Intelligence Server). MicroStrategy Intelligent Cube упрощает выполнение анализа и развертывания, предоставляя сводную информацию для быстрого просмотра в интерактивном режиме. С помощью Intelligent Cube можно углубляться в данные и выполнять ROLAP анализ информации на уровне транзакций.

MicroStrategy Narrowcaster дает пользователям возможность пересылать показатели или подписываться на них через Web-интерфейс. Пользователи могут пересылать по электронной почте свои отчеты, планировать пересылку отчетов, публиковать их для рабочих групп и экспортировать в Excel, PDF или HTML-форматы.
Продукт предоставляет ряд функций:

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

функции анализа данных;

возможность совместного использования информации как в как в Intranet, так и в Extranet


Cognos Powerplay Web Edition – продукт, позволяющий осуществлять оперативную аналитическую обработку в Web. По своим возможностям не уступает обычной (несетевой) версии.

Интеграция.

Структура приложений Alphablox основывается на стандартах и допускает интеграцию с существующими операционными системами, транзакционной инфраструктурой, с традиционными (legacy) системами. Компании могут встроить аналитические функции в свои бизнес процессы напрямую, используя существующие Web IT-инфраструктуры. Аналитика внедряется как внутри предприятия, так и вне его, через системы сетевой защиты, и предоставляется клиентам, партнерам и поставщикам. Более того, решения от Alphablox масштабируются для тысяч пользователей, по множеству подразделений компании с использованием стандартных отраслевых моделей защиты, обеспечивающих конфиденциальность информации.
Программное обеспечение можно разрабатывать таким образом, чтобы использовать бизнес-логику из различных систем (CRM, ERP, Alphablox) в одном JSP-приложении.

Доступность и переносимость.

WebIntelligence является «тонким» клиентом, не требует установки и сопровождения ПО приложений или промежуточного ПО БД на клиентском месте. При установки клиентской части предусмотрена возможность выбора технологии: HTML, DHTML, Java или ActiveX. WebIntelligence предоставляет возможность глобального внедрения BI-средств в Web.

Применение HTML/JavaScript, предоставляющее универсальный доступ для любого пользователя, работающего с Netscape Navigator версии 3.0 и выше или Microsoft Internet Explorer.

Доступ к BPM/OLAP для любого пользователя организации.

Создание и публикация BPM-отчетов (Business Performance Management – Управление эффективностью бизнеса) в виде PDF-документов для Cognos Upfront портала, благодаря чему пользователи имеют доступ к наиболее важным корпоративным данным в среде Web.

Преобразование данных из PDF-формата в динамические отчеты, их дальнейшее исследование и передача результатов на Upfront.

Сервер поддерживает работу с платформами: Windows NT, Windows 2000, Windows XP, SUN Solaris, HP/UX и IBM AIX.

Переносимость.

Обеспечивается межплатформенная поддержка и интеграция, переносимость в Unix, поддержка серверов приложений «третьих» фирм.

Поддержка различных источников данных.

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

Архитектура.

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

Открытая XML-архитектура.

В основе продукта лежит XML-архитектура. Компании могут интегрировать XML-код, сгенерированный в MicroStrategy Web, в свои приложения, или форматировать его нужным образом.

Повышение производительности.

Alphablox максимально использует ресурсы и возможности сервера приложений, в том числе http обработку/кэширование и управление памятью/процессами, а также интреграцию с Web-серверами. Кроме того J2EE-совместимая архитектура устраняет излишнее обновление страниц и позволяет выполнять основную логику на сервере.

Web-архитектура.

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

Безопасность.

Alphablox использует ту же модель защиты, что и сервер приложения, реализованную с помощью стандартных API платформы J2EE. За счет этого устраняется необходимость в создании независимой модели механизма защиты в Alphablox.

Доступность и Интеграция.

Тонкий клиент, реализованный в формате HTML, устраняет проблемы совместимости с браузерами, развертывается через все средства сетевой защиты. Поэтому такой продукт подходит для использования как в intranet, так и в extranet.
Вид и функции приложения можно настроить под конкретные нужды. В результате, можно встраивать MicroStrategy Web в другие Intranet или Extranet приложения.
BI-средства должны поддерживать интеграцию всех компонентов вычислительной среды предприятия. Интерфейсы пользовательских приложений, реализованные в MicroStrategy SDK включают MicroStrategy Portal Integration Kit и MicroStrategy Web Services Development Kit.Portal Integration Kit позволяет использовать возможности поиска для порталов «третьих» фирм. Web Services Development Kit обеспечивает XML- и SOAP-интерфейсы.

Интеграция. Независимость от источников данных.

Предусмотрен доступ ко всем основным OLAP серверам, включая PowerPlay PowerCubes, Microsoft OLAP Server, Hyperion Essbase, SAP BW and IBM DB2 для OLAP.

Независимость от источников данных и интеграция.

С помощью WebIntelligence можно исследовать и анализировать различные OLAP источники, а также использовать совместно OLAP и реляционные данные. Если анализ плавно переходит от OLAP-сервера к реляционным отчетом, программа WebIntelligence находит эквивалентные объекты в обеих средах и выдает только согласованные результаты.
Продукт настраивается таким образом, чтобы в наибольшей степени соответствовать корпоративной структуре. В Businessobjects Developer Suite представлены функции для настройки WebIntelligence на языках ASP (Active Server Pages), JSP (Java Server Pages), также расширенная объектная модель SDK. Продукт напрямую интегрируется в другие приложения, исполняющиеся на сервере.

Масштабируемость и надежность.

Компьютеры, на которых работает MicroStrategy Web, можно объединять в кластеры, чтобы обеспечить масштабируемость и надежность. При необходимости предусмотрено добавление дополнительного оборудования. Если происходит сбой при выполнении задания, оно передается на другую машину из того же кластера.

Масштабируемость.

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

Ðабота с несколькими серверами как в Windows, так и в Unix позволяет тысячам пользователей обращаться к корпоративным отчетам и кубам.

Стоимость.

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

Обеспечение безопасности.

Данные защищены на уровне ячеек с использованием фильтров защиты и списков управления доступом. Безопасность Web-трафика обеспечивается технологией шифрования данных на транспортном уровне - SSL (Secure Sockets Level – Уровень защищенных сокетов).
Специалисты по защите информации рекомендуют такие архитектуры, где web-сервер не соединяется с базами данных. В отличие от продуктов многих других производителей, MicroStrategy Web не имеет прямого доступа к базам. В результате БД всегда защищены от взлома.

WebIntelligence использует различные технологии защиты информации, включая авторизацию, брандмауэры (системы сетевой защиты), DMZ («демилитаризованная зона» - часть сети, находящаяся между локальной сетью и Интернетом), SSL и прокси-серверы. При необходимости компоненты (Java или ActiveX) помечаются с помощью технологии цифровых сертификатов. Для работы с разными системами сетевой защиты и поддержки DMZ используется протокол передачи гипертекста (HTTP). При этом не требуется вносить изменения в существующую конфигурацию брандмауэров. Это является ключевым требованием, гарантирующим безопасную среду между компаниями, развертывающими BI–приложения.


Благодаря поддержке протокола SSL, PowerPlay гарантирует защищенность данных, посылаемых через Web. Кроме того, задавая классы пользователей (User Classes), системные администраторы могут контролировать их доступ, как к локальным кубам, так и в оболочке Web-портала.
Эти классы хранятся в специальном, доступном по протоколу LDAP (Light Directory Access Protocol – Облегченный протокол доступа к сетевому каталогу), программном компоненте, который отвечает за централизованное управление безопасностью всей системы, а также за интеграцию с текущей защитой.
Использование HTML для реализации клиентских мест допускает функционирование сервера PowerPlay в защищенной среде. Тем самым обеспечивается безопасное развертывание приложений для клиентов, партнеров и поставщиков.

Стоимость.

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

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


Продукт является «тонким» клиентом, реализован в виде «чистого» HTML-решения, за счет чего гарантируется низкая стоимость развертывания проекта. На освоение продукта пользователем требуется минимальное время, что также сокращает затраты. Добавим, что использование многоязычных серверов позволяет пользователям выбирать язык при просмотре и анализе корпоративных данных. Это существенно сокращает затраты на внедрение продукта на крупных международных предприятиях.

AlphaBlox

AlphaBlox – связующее ПО, предоставляющее API инструментарий и компоновочные блоки для работы в Web. Благодаря этому, устраняются все сложности, связанные с кодированием соединений с базами данных, авторизацией и форматированием данных. Аналитическая платформа AlphaBlox, реализована на основе стандартизованной J2EE-совместимой архитектуры.
Alphablox предлагает новый подход. В отличие от традиционных BI-инструментов, разработанных для анализа дискретных автономных процессов, продукты Alphablox спроектированы специально для активной, распределенной аналитики внутри и вне предприятия.
Особый интерес представляют собой Java-компоненты (Blox), напоминающих элементы конструктора Lego. Из этих компонентов, можно собрать аналитическое Web-приложение. Одна из самых трудоемких задач при создании Web OLAP-продукта – отображение и форматирование данных в браузере. Очень часто данные нужно показывать в виде таблицы (grid) или диаграммы. При создании приложения с использованием Alphablox в него можно вставить любое количество Blox и настроить их для решения нужных задач, задавая определенные параметры апплетов, а также используя API, и тем самым контролируя вид и функции компонентов.

Перечислим основные преимущества этого продукта.

Business Objects WebIntelligence

 WebIntelligence – Web-продукт для создания запросов, отчетов и анализа данных. Предоставляет пользователям сети (как Intranet, так и Extranet) защищенный доступ к данным для их последующего исследования и управления.

Cognos Powerplay

Cognos PowerPlay Web Edition позволяет проводить многомерный анализ и создавать отчеты по OLAP-данным в Web-среде. Выполнив аналитическую обработку, можно опубликовать полученные отчеты на портале Cognos Upfront, т.е. сделать их доступными для остальных коллег и партнеров. Последние же, преобразовав файлы из PDF-формата в динамические Web-отчеты (в формате PowerPlay), смогут исследовать эти OLAP-данные и затем уже поделиться своими результатами с другими пользователями портала.
Характеристики Web-версии:

Функциональность

Компоненты Blox обеспечивают следующие возможности:

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

Запросы и анализ. Компоненты выполняют простые и сложные запросы к различным источникам данных, при этом не требуется программирования на SQL.

Представление. Blox представляют данные в различных форматах (в виде отчетов, таблиц, диаграмм) и помогают пользователю при выполнении анализа. Java-компоненты имеют модульную структуру и могут использоваться многократно. Их можно применять при реализации аналитических возможностей для множества бизнес-функций. Так как они управляются набором параметров, то их свойства можно изменять с помощью любого HTML-редактора или Java IDE. Это дает полную гибкость при разработке и модернизации аналитического решения. Компоненты можно настраивать для удовлетворения определенных бизнес-требований и повторно использовать, внедряя дополнительные приложения в других областях деятельности. Разработчики приложений могут писать дополнительный код на JSP, JavaServlets или на языке JavaScript.
Alphablox-решения используют сервисы, предоставляемые сервером приложений и средой Java Runtime Environment (JRE), любые Java-расширения или заказные расширения, разработанные для этой платформы.
Хотя возможности связующего ПО Alphablox велики, у него есть и некоторые недостатки. Нет полной функциональности для манипулирования данными. AlphaBlox обеспечивает доступ и форматирование – это функции связующего ПО. Большинство же BI-приложений на рынке предоставляют сложные функции обработки данных. Сортировка, ранжирование, вычисление стандартных отклонений и дисперсий – вот лишь малая часть тех возможностей, которые есть у многих клиентских инструментов. Такая функциональность очень важна для выполнения сложного анализа данных предприятия. У AlphaBlox же она отсутствует, за исключением некоторых возможностей сортировки. Однако, выполняя роль промежуточного ПО AlphaBlox может передавать данные другим в другие программы, осуществляющие эту обработку, например в Excell или Java-приложение.

Критерии успеха Web-средств Business Intelligence

Прежде чем перейти к описанию конкретных продуктов остановимся на тех критериях, которые определяют успех Web-OLAP продукта на рынке.

Таблица 1. Критерии успеха Web-Olap решения

Критерий	Описание
1. Удобство использования	Успешный BI-продукт должен быть достаточно прост для неопытного пользователя, не имеющего специальной подготовки.
2. Интерактивность	Программное средство должно реализовывать интерактивные возможности, в том числе: просмотр статических документов; динамическое обновление существующих документов, обеспечивающее доступ к самой свежей информации; динамическое выполнение нерегламентируемых запросов к источникам данных; динамическое неограниченное «углубление в данные» (drill-down).
3. Функциональность	Web-BI приложение должно обеспечивать такие же возможности, как и традиционные клиент/серверные аналоги, удовлетворяя при этом дополнительные требования. Генерирование SQL, выполнение динамических пользовательских расчетов, различные методы навигации – все это необходимо и в Web.
4. Доступность и переносимость.	Главное преимущество Web – доступность и переносимость. Информация должна быть доступна для любого устройства, рабочего места, в любой точке земного шара. Вне зависимости от того, находятся ли данные в главном управлении компании, в удаленных офисах, у коллеги на его/ее рабочем месте или на портативном устройстве. Клиентская часть идеального BI-продукта должна быть небольшой, чтобы удовлетворить различным уровням пропускной способности сети пользователя, а также соответствовать стандартизованной технологии.
5. Архитектура	Поскольку Web-среда принципиально отличается от традиционной клиент/серверной, здесь возникает множество новых технологических проблем. Многозвенная архитектура, допускающая наличие различных типов клиентов (Java, HTML и т.п.), а также «собственное» соединение с Web-сервером (NSAPI, ISAPI) и сервером базы данных – необходимы для корпоративного программного продукта.
6. Интеграция. Независимость от источников данных	Корпоративная вычислительная среда содержит различные виды аппаратных и программных ресурсов, пакетных приложений и баз данных. Хорошо разработанное BI-приложение должно давать доступ к статическим документам любого типа (а не только тем, которые оно само создает), а также интерактивный доступ к реляционным и многомерным базам данных, приложениям и другим источникам.
7. Производительность и масштабируемость	Для обеспечения производительности и масштабируемости в Web необходимо реализовать следующие возможности: Балансировку нагрузки сервера приложения, Собственное соединение с web-сервером, Собственный доступ к базе данных. Кэширование сервером приложения (данных или соединений с базой). Персистентность, устраняющую проблему хранения состояний в Web.
8.Обеспечение безпасности	Возможность администрирования через web – одно из ключевых преимуществ. Так, для изменения прав конкретного пользователя администратору не нужно появляться на его/ее рабочем месте. Используя модули администрирования, можно создавать профили для отдельных пользователей или групп, предоставляя доступ только к авторизованной информации.
9. Стоимость внедрения и администрирования	Стоимость внедрения Web-OLAP решения в расчете на одного пользователя должна быть существенно ниже, чем для традиционных продуктов. Поскольку поддержка клиента очень сложная задача для традиционных клиент/серверных продуктов, Web-решения устраняют часть накладных расходов, не требуя специального клиентского ПО, кроме браузера. Расходы на администрирование становятся значительно меньше, если: снижается стоимость поддержки клиентской части ПО; снижается стоимость поддержки серверной компоненты; программа может эффективно функционировать в Web-среде, где распространяются тысячи отчетов/документов и тысячи пользователей нуждаются в защищенном интерактивном доступе к разным базам.

Microstrategy

MicroStrategy 7i – набор программных продуктов с широким диапазоном функций, построенный на унифицированной серверной архитектуре. Пользовательская среда реализована в MicroStrategy Web Professional. Для построения инструментов конечного пользователя используется Web-технология «тонкого» клиента на основе DHTML.

Обзор OLAP-продуктов для Web

Дата: Май 2003 года
Подготовлено: по материалам зарубежных сайтов
Перевод: Intersoft Lab

Обзор продуктов

Рассмотрим Web-OLAP средства от трех крупных поставщиков: Microstrategy, Business Objects и Cognos. Оценим эти продукты в соответствии с предложенными выше критериями. Затем опишем еще одно интересное решение (фирмы AlphaBlox), представляющее собой ПО промежуточного уровня для разработки Web-OLAP приложений.

Рынок OLAP-средств: быстрый рост, вызванный развитием Internet-решений

Как показал проведенный нами анализ, Web-архитектуры быстро вытесняют традиционные клиент/серверные приложения для целого ряда категорий программного обеспечения, и рынок корпоративных OLAP-решений здесь не исключение.
Это направление стремительно развивается за счет появления различных Web-OLAP инструментов на базе HTML- и Java-технологий от известных поставщиков и быстро растущих новых компаний. В связи с расширением контингента пользователей продукты Web-OLAP разрабатываются для выполнения несколько иного анализа, чем традиционные клиент/серверные инструменты. Происходит переход от инструментальных средств исследования данных, ориентированных на специалистов-аналитиков, к готовым аналитическим приложениям, доступным для более широкого круга пользователей.

И все же, какова реальная

И все же, какова реальная ситуация на рынке Web-OLAP средств? Обратимся к мнению экспертов.
Старший аналитик в области разработки приложений компании Meta Group Дон Мактэвиш (Don MacTavish) считает, что наиболее привлекательные Web-OLAP решения принадлежат не старым поставщикам, а новым компаниям (например AlphaBlox), которые предлагают модульные платформы для создания аналитических приложений. Наиболее перспективными представляются продукты от AlphaBlox, InfoSpace, Hyperion и Seagate Software. Мактэвиш утверждает, что хотя традиционные поставщики OLAP (такие как Cognos, Business Objects и Brio) и делают шаги вперед, предлагая Web-решения, их разработки часто оказываются не самыми лучшими. Однако он отметил интересную архитектуру приложения Webintelligence от Business Objects.
Тереза Уингфилд (Teresa Wingfield), руководитель исследовательских работ в компании Giga Information Group, также выделила архитектуру Business Objects, но при этом добавила, что на рынке лидируют Web-продукты компании MicroStrategy.
Развитие решений с тонким клиентом вовсе не означает, что толстый клиент уже отжил свое. Большинство поставщиков OLAP-продуктов предлагают свои решения, как на традиционном, так и на Web-рынке. Мактэвиш утверждает, что: «Мощный клиент сохраняет свою ценность».
Дэн Дракер (Dan Druker), вице-президент отдела маркетинга компании Hyperion Solutions, отмечает, что многие фирмы используют Web-решения для массового распространения информации, сохраняя традиционные мощные инструменты для выполнения более сложного анализа. «Это вопрос выбора», – добавляет он.

Архив без пыльных полок или способы организации архива предприятия

Алексей Рындин (Главный инженер проектов),
Опубликовано в журнале JetInfo ВступлениеОписание проблемы архивного хранения информацииИстория развития решенияОсновная частьЧто же такое "Электронный архив предприятия"?Различные взгляды на состав решенияС чего начать?Заключение Думаю, услышав словосочетание "пыльные полки", читатель представит архив, причем не обязательно исторический. Возможно это будет архив его предприятия. Так уж сложились наши взгляды. Не верите? Тогда попробуйте зайти на сайт поисковой системы Яндекс (http://www.yandex.ru), ввести, например, словосочетание "пыльные полки архивов" и посчитать число найденных страниц...

PLM - не роскошь, а необходимость

27.06.2003
С наступлением нового века мы становимся свидетелями тектонических сдвигов в представлениях о том, что такое информационная система предприятия. Не исключено, что наблюдаемые сегодня явления, — это начало процессов, смысл которых станет очевидным через какое-то время. Одним из предвестников грядущих перемен можно признать new PLM — «новое управление жизненным циклом изделий». Новый взгляд на PLM наряду с изменениями в технологиях интеграции приложений и архитектуре корпоративных систем позволяет представить предприятие как единый управляемый организм. До последнего времени внедрение компьютеров на промышленных предприятиях не было напрямую связано с конечной целью их существования, которая, очевидно, состоит в получении прибыли на основе выпуска и продажи продуктов. Из-за ограниченности технических средств предпринимались разрозненные попытки автоматизировать отдельные, зачастую не самые критичные, частности. Если исключить единичные уникальные проекты, то начало массовому внедрению компьютеров в 60-е годы было положено расчетом заработной платы; компьютер тогда в основном воспринимался как счетное устройство. В 70-е годы с появлением машинной графики начали активно развиваться системы автоматизированного проектирования и технологической подготовки производства (CAD/CAM). В 80-е годы СУБД, персональные компьютеры, архитектуры «клиент-сервер» и другие типичные для того времени технологии открыли широкие возможности для решения самых разнообразных учетных задач, документооборота и т.д. Но системы, которые по привычке называют информационными, так и не вышли на уровень управления предприятием в целом; они остаются вспомогательными и по своей значимости не могут рассматриваться наравне с основными средствами производства. Как следствие, постоянные сомнения в отношении экономической стороны компьютинга, наиболее образно выраженные в известном «парадоксе продуктивности»: «Компьютеры можно обнаружить всюду, кроме отчетов об их экономической эффективности».
События последних лет показали, что период созревания ИТ-отрасли закончился: с одной стороны, накоплена достаточная сумма технологий, а с другой — инвесторы требуют расчета «по гамбургскому счету», желая вкладывать средства во что-то более определенное.
В новой кризисной экономической реальности особые надежды возлагаются на PLM (Product Life-cycle Management).

Рассмотрим, например, следующее сравнение. В сложной автономной системе, скажем, в ракете, отдельные подсистемы автоматизации образуют единое целое; такой аппарат может обходиться и без пилота. В современном автомобиле есть множество систем автоматизации, но решающую роль в управлении пока играет человек, поэтому автоматике отводится второстепенная роль; в принципе, без нее вполне можно обойтись. В автомобиле отдельные подсистемы логически связаны между собой только через посредство водителя. До сих пор примерно то же самое наблюдается и в корпоративных системах; хорошо известные системы категорий CAD, CAM, ERP, CRM, BI и т.д. желательны, но не обязательны и, в известной мере, вторичны. Без них тоже вполне можно обойтись, никем научно не доказано их влияние на показатели работы предприятия в целом. Однако с наступлением очередной фазы электронного бизнеса ситуация меняется. Системы автоматизации становятся обязательными, приобретают первостепенную значимость и теперь должны образовывать единую систему управления. По мнению многих аналитиков, тем зонтиком, под которым они объединятся, может стать управление жизненным циклом продуктов PLM.

Если аналитики и расходятся во мнениях относительно PLM, то только по степени оптимизма в предсказаниях темпов роста. «Универсальная» аналитическая компания IDC оценивает рынок управления жизненным циклом изделий суммой 3 млрд. долл. в 2002 году [1]. Его объем возрастет до 9,7 млрд. долл. в 2007 году, а средний ежегодный прирост составит 26,1%. Меньшая по размерам аналитическая компания ARC Advisory Group специализируется на области PLM. Ее оценки таковы: рынок PLM в 2002 году — 5,6 млрд. долл., в 2007-м — 14 млрд., ежегодный прирост на прогнозируемый период — 20% [2]. Разброс в оценках в ARC аргументируют так: «Управление жизненным циклом продуктов скорее стратегия, чем конкретные продукты. Сегодня ни одна компания не поставляет законченного решения PLM, в своем нынешнем состоянии PLM наследует из двух областей: автоматизация проектирования (Computer-Aided Design, CAD) и управление данными об изделиях (Product Data Management, PDM).


Обзор участников рынка PLM можно найти на весьма полезном сайте консалтинговой компании John Stark Associates ().

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

Рис 1. Классификация этапов развития электронного бизнеса по Gartner Group

Хорошо известна классификация электронного бизнеса, предложенная компанией Gartner Group (рис. 1). Она делит его на четыре фазы развития: присутствие, взаимодействие, передача данных (транзакции) и трансформация бизнеса. Начиная с 2000 года, активно развиваются третья и четвертая фазы. Есть менее известная, но более содержательная и тоже четырехуровневая классификация этапов развития электронного бизнеса, предложенная Дэйвом Фишером из компании i2 (рис. 2).

Рис. 2. Четыре поколения электронного бизнеса по Фишеру

Она основана на том, как используются данные: развитие электронного бизнеса по Фишеру [3] можно рассматривать как восхождение от простого обмена данными к обеспечению средствами технологий потоков работ и потоков принятия решений. Реальное использование Internet-технологий в области PLM стало возможным только на нынешнем, более высоком уровне развития электронного бизнеса. Нет ничего удивительного в том, что радикальные изменения происходят именно сейчас: практически за всеми наблюдаемыми тектоническими подвижками стоит трансформация философии построения систем, определяемая Web-службами. Их слабая связанность, асинхронность и ряд других качеств стали важнейшим фактором влияния (X-Factor), который меняет мировоззрение.Сегодня еще нет системы устоявшихся взглядов; специалисты из разных областей еще сидят по своим кабинетам и говорят на разных языках. Самые интересные события начнутся тогда, когда за одним столом соберутся вместе специалисты по интеграции приложений (Business Integration) и по PLM.

PLM по-новому

Современный бизнес решает триединую задачу: во-первых, необходимо устанавливать более тесные и доверительные отношения с поставщиками и заказчиками, во-вторых, повышать уровень собственной операционной эффективности и, в-третьих, повышать конкурентоспособность выпускаемой продукции. Первая составляющая обеспечивается системами поддержки отношений, получающими все большее распространение — системами SCM и CRM, вторая — еще более популярными системами ERP, а вот третья пока не имеет достаточного комплексного информационного обеспечения. На то, чтобы занять это место, претендует подход, названный new PLM. Он заметно отличается от традиционного представления о том, что такое управление жизненным циклом изделий [4]. Раньше под PLM (в узком смысле) чаще всего понимали то, что имело отношение к жизненному циклу материальных изделий, начиная от запуска в производство, регулирования объемов выпуска, определения времени выпуска новых или обновленных изделий и, конечно же, сопровождение и сервис. Изменения в видении роли и места PLM произошли буквально в последние несколько лет. Теперь под этим термином понимают автоматизацию практически всех видов работ, которые составляет основу выпуска продукции — от проектирования до сбыта. Разные авторы расходятся в определениях; одни включают SCM, CRM и ERP в состав нового управления жизненным циклом изделий, другие [5] считают эти системы взаимодополняющими (рис. 3).

Рис. 3. Взаимосвязь между корпоративными приложениями

В материале IBM [6], может быть, потому, что он подготовлен в 2000 году — SCM, CRM и PLM поставлены в один ряд, а объединяют их в одну системы ERP и BI. В любом случае все эти подсистемы обеспечивают жизненный цикл изделий вне зависимости от того, каким именно образом они интегрируются.
По меркам компьютерной эры у PLM давняя история. Системы PLM появились примерно два десятилетия назад, но вскоре возникла необходимость отделить автоматизацию процессов проектирования и подготовки производства (CAD/CAM) от управления информацией, сопровождающей изделия.
Тогда появилось самостоятельное от CAD/ CAM направление Product Data Management (PDM), т. е. управление данными об изделиях [7]; в основном оно связано с документооборотом конструкторской и технологической документации. Те, кто хоть как-то знакомы с тем, что такое выпуск и перевыпуск конструкторской документации, могут оценить значение систем управления такого рода документооборотом. Для тех, кто не знаком, может оказаться полезным слышанное от авиационных конструкторов утверждение: «Документацией на современный истребитель можно загрузить целиком большой транспортный самолет». Однако как бы ни была важна задача управления такими потоками данных, программное обеспечение PDM применялось на уровне конструкторских и технологических подразделений, не выходя на корпоративный уровень. Инструментарием PDM пользовались менеджеры не выше среднего звена.

В условиях современного рынка скорость обновления продуктовой линейки становится критически важной для конкурентоспособности предприятия, от PLM требуется, чтобы предлагаемые средства стали инструментами для менеджеров уровня CxO — CIO, CTO, CFO, ..., а в некоторых случаях, и для CEO.

В соответствии с триединой задачей «PLM по-новому» можно разделить на три взаимосвязанных составляющие управления жизненным циклом:

жизненный цикл определения изделий (интеллектуальные активы предприятия);

жизненный цикл производства (материальные активы предприятия);

жизненный цикл операционной поддержки.

Рис. 4. Основные жизненные циклы: 1 - Жизненный цикл определения изделия. Интеллектуальный капитал 2 - Жизненный цикл производства изделия. Физический капитал 3 - Операционный жизненный цикл изделия. Ресурсы

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


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

Поверх первого цикла накручивается второй — производственный; он включает все, что связано с выпуском и распределением выпущенной продукции. Основными приложениями, реализующими функции этого цикла, являются системы управления ресурсами предприятия (ERP). Внешний, операционный цикл поддерживают системы управления финансами, кадрами и другими ресурсами (CRM, SCM и др.).

Одно из наиболее полных определений PLM [5] состоит из четырех пунктов:

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

поддержка «расширенного представления о предприятии» (extended enterprise), в том числе поддержу процессоров проектирования, пользователей и партнеров;

действие во времени от момента рождения концепции изделия до снятия его с производства и окончания сервисного периода;

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


На основании этого определения выделяются три основные концепции PLM:

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

поддержание целостности информации, определяющей изделие, на протяжении всего его жизненного цикла изделия;

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

Возникает вполне естественный вопрос, насколько реалистичны приведенные выше рассуждения. В [8] вопрос этот поставлен так: «Что станет полем битвы для корпоративных приложений, будет ли это PLM?» Ответ на него скорее положителен, чем отрицателен. PLM рассматривается не только как возможность повысить эффективность капиталовложений. Главное достоинство этого бизнес-подхода — в возможности увидеть проблемы производства в целом (360-degree view of the product). Он позволяет интегрировать всех участников жизненного цикла изделия, от инженеров до вспомогательных служащих.

Как скажется увлечение PLM на индустрии программного обеспечения, пока сказать трудно. Можно только отметить тенденцию развития от коробочных продуктов к комплексным решениям. Одним из примеров движения в этом направлении демонстрирует корпорация Oracle, начавшая с СУБД, затем ставшая поставщиком прикладных решений, и еще более усиливающая свои позиции в этом качестве сегодня, пытаясь приобрести компанию PeopleSoft.

Системный подход в автоматизации процессов компаний

К.т.н. И.М. Слюсаренко, к.т.н. М.Ю Слюсаренко, «InfoSoftCom» В статье описаны основные черты системного подхода. Показано его место в процессе автоматизации деятельности компаний. Кратко описано направление развития системного подхода в вопросе его применения для создания решений в сфере автоматизации деятельности предприятий и компаний. Обоснована необходимость применения данного подхода в течение всего жизненного цикла программно-аппаратных систем, призванных автоматизировать тот или иной бизнес-процесс компании. В общих чертах рассмотрены возможные ошибки автоматизации и их возможные причины. Рано или поздно в любой развивающейся компании возникает идея автоматизации своей деятельности, а сама автоматизация рассматривается как спасательный круг, способный решить если не все проблемы компании, то их значительную часть. Отчасти данное суждение сформировано маркетинговой рекламой ведущих консалтинговых фирм, отчасти верой в «чудо». Несомненно, автоматизация способна повысить эффективность деятельности компании, однако в практике консалтинговых компаний есть немало примеров, мягко говоря, неудачных автоматизаций. В качестве основных причин таких провалов обычно рассматривается нежелание управленческого звена менять стиль деятельности, наличие семейных, родственных контуров принятия решений, которые невозможно автоматизировать, ошибки специалистов консалтинговой компании и т.д. Можно высказать предположение, что причины ошибок лежат гораздо глубже, чем это видится на первый взгляд. Прежде всего, необходимо отметить, что компании, особенно крупные, относятся к объемным, сложным образованиям и им присущи все закономерности возникновения, становления, развития, свойственные сложным системам, изучаемым теорией сложных систем [1] или системологией [2]. В системологии под системой понимается устойчивое образование, обладающее некоторым компонентным составом и структурой. Под компонентой или элементом понимается элементарное, неделимое в данном рассмотрении материальное образование, под структурой – устойчивые взаимосвязи между элементами, которые объединяют элементы в систему.
Системы, как правило, находятся в окружении других систем, с которыми вступают во взаимосвязи различного вида. Наличие устойчивых взаимосвязей между системами и появление новых системных качеств данного объединения (эмергентных свойств) позволяет определить наличие системы более высокого уровня. В этом случае входящие системы будут подсистемами системы более высокого уровня. По своей сути, с точки зрения системологии, процесс автоматизации компании является процессом создания новой системы, состоящей из ряда старых подсистем (например, отделов компаний), и ряда новых подсистем (учитывая мировые тенденции развития, скорее всего аппаратно-программных). Процессы описания, создания систем и методы, обеспечивающие выполнение этих процессов, достаточно подробно описаны в теории систем. Применение данных методов и системологии, чаще всего обозначают термином «системный подход». В настоящее время автоматизация деятельности компании обычно выполняется на основе регламентации и моделирования бизнес-процессов компании [3]. С этой целью разработан ряд описательных языков, нотаций, и программных средств на их основе, призванных автоматизировать процесс построения данных моделей. В качестве примера таких языков и нотаций можно привести следующие (наиболее популярные): UML (Unified Model Language) и BPNM (Business Process Modeling Notation). На первом рисунке в качестве примера приведено описание фрагмента бизнес-процесса планирования строительно-монтажных работ с помощью BPNM 1.0. С помощью средств, описанных выше, разработано значительное число типовых аппаратно-программных продуктов, адекватно обеспечивающих выполнение целого ряда типовых бизнес-процессов в сфере производства и продаж. Необходимо отметить, что при этом выделяется одна существенная черта систем – наличие в ней устойчивых процессов. С точки зрения системологии при такой автоматизации охватываются взаимосвязи между элементами типовой системы и(или) с другими типовыми системами [4]. Другими словами, такие продукты рассчитаны на некую усредненную (типовую) компанию, в которой выполняются типовые бизнес-процессы.


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


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

Электронный технический документ: возьми то, не знаю что...

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

Применение ЭТД требует управления применением ЭЦП, а последнее основывается на специфике электронного представления ЭТД. Между тем Федеральный закон об электронной цифровой подписи определяет электронный документ как «документ, в котором информация представлена в электронно-цифровой форме». К сожалению, такое определение говорит об информации, но не о самом документе, и уж тем более о специфике ЭД. Необходимость работы с ЭД и ЭТД заставляет предприятия самим давать определения этим терминам, разрабатывать собственные системы правил и механизмы управления ЭЦП и ЭД, что порождает множество различий в реализациях, часто принципиальных. При интеграции с информационными системами других предприятий возникают неизбежные коллизии или несовместимость. И если люди с их интеллектуальной системой обработки данных и принятия решений могут договориться в таких случаях, то их компьютерные системы здесь бессильны — им нужны стандартные интерфейсы и протоколы обмена.

Некоторые определения

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

Система управления техническим документооборотом: кошка, которая гуляет сама по себе?

Исторически сложилось так, что технический документооборот и его автоматизация никогда не рассматривался ни как самостоятельная дисциплина, ни как комплексная система управления. Были и есть стандарты ЕСКД, ЕСТД и других групп, отраслевые стандарты, в которых технологические, организационные и процедурные вопросы, связанные с технической документацией и документооборотом достаточно хорошо отработаны и проверены десятилетиями. Сама же система управления была «человеко-ориентированной» и что чрезвычайно важно — интеллектуальной (т.к. средством всевозможных операций над документами, средством информационного взаимодействия, средством разрешения коллизий была и есть единственная интеллектуальная унифицированная природой «вычислительная машина» — человек). Это позволяло решать задачи управления документооборотом фактически в фоновом режиме при сохранении слабо формализованного информационного взаимодействия его участников. Такое положение дел долгое время оставалось неизменным во время автоматизации систем создания и подготовки инженерных данных. Это подтверждает и тот факт, что категории Docflow и Workflow появились не в виде самостоятельных систем, а как вспомогательные модули к различным системам PDM, ERP и САПР и бизнес-приложениям.
Такая потеря самостоятельности ЭТДО и сегодня играет злую шутку с отечественными предприятиями: вместо создания современных систем управления документами и деловыми процессами предприятия по-прежнему концентрируют свое внимание на задачах создания и подготовки содержимого документов (технических данных). Методы и средства управления документооборотом фактически оказались без изменений. Таким образом, задача автоматизации управления ЭТДО фактически является придатком систем создания и обработки электронных технических данных. В результате не используется один из самых важных инструментов, способных повлиять на бизнес-технологии, в том числе на переход к процессно-ориентированной организации бизнеса.

Технический документооборот: Система

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

Миф 2. Надежное хранение документов — значительно снижается вероятность потери документа или доступа к нему лиц, не имеющих на это права. Хранение имеет смысл только в контексте того, что пользователь, передавший документ на хранение, получит его по запросу. Если вы точно знаете, что документ находится и надежно хранится в хранилище, а найти или получить его не можете, то какая вам от этого польза? Однако при неправильной организации системы хранения электронных документов, последние намного уязвимее, чем системы хранения традиционной документации. Вот несколько причин этого.

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

Электронные хранилища более климатически и энергозависимы.

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

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

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

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


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

электронные технические документы (ЭТД);

связанные с ЭТД электронные технические данные;

двухмерные и трехмерные модели, с учетом особенностей хранения части данных в базах данных управляющих программ (САПР, PDM), обеспечивающих работу с этими моделями;

ПО, на котором велась обработка документов и данных, хранящихся в архиве;

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

Миф 3. Внедрение ПО управления ЭТДО резко увеличивает эффективность управления деловыми процессами. Зарубежная статистика приводит цифры об увеличении производительности при автоматизации управления деловыми процессами (УДП) на 30-40%. Но причины этого кроются не только в возможностях, предоставляемых компьютерными технологиями, но и в изменении технологии выполнения этих процедур и в дисциплине труда. Во-первых, переход к АСУ ЭТДО требует организационной и управленческой зрелости предприятия, как исходного состояния для эффективной автоматизации УДП. Нашим предприятиям до такого состояния пока далеко: даже не прибегая к автоматизации УДП, только за счет организационных изменений можно поднять эффективность УДП не на 30-40%, а на все 100-200% и более.


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

В-третьих, эффективное автоматизированное УДП в ЭТДО возможно только при сквозной интеграции потоков работ и документов между всеми приложениями, осуществляющими УДП. Это сама по себе чрезвычайно сложная задача, процесс стандартизации которой начался совсем недавно (первые стандарты появились в 1999 году) и активно продолжается коалицией Workflow Management Coalition. Эти стандарты пока реализованы в весьма небольшом количестве продуктов таких известных разработчиков, как SAP AG, BAAN, IBM и некоторых других. К сожалению, наши разработчики средств управления документооборотом этим похвастаться не могут, но зато многие декларируют «соответствие требованиям стандартов и принципов создания открытых систем». Максимум, что предлагается нашими разработчиками — точечная интеграция между отдельными средствами УДП, основанная на частных нестандартных спецификациях обмена. Отличительная особенность этих спецификаций — опора на текущие программные реализации продуктов де-факто (т.е. в лучшем случае — на внутрифирменные стандарты производителей, в худшем — на логику разработчиков программного обеспечения). Решения на базе таких интеграционных решений обычно «сыпятся» при переходе на новую версию продукта или при изменении опорных технологий, и на все сто процентов зависят от разработчика.

Миф 4. Cодержание бумажных архивов обходится предприятиям на 80% дороже, нежели архивов электронных. Может быть, если дело касается архивов нетехнических документов. Что же касается архивов технических документов, то говорить о стоимости их содержания пока что рано. Сначала неплохо было бы просчитать, во что выльются вложения в разовые работы: обследование предприятия, проектирование и создание программно-технического комплекса, оцифровка бумажного архива, разработка системы управления применением ЭЦП, разработка новой технологии работы и регламентов работы с ЭТД, гармонизация с системой традиционного документооборота, обучение персонала, переход на новую технологию.


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

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

Время действовать системно

Создание и внедрение системы управления электронным документооборотом есть неотъемлемая часть изменения бизнес-технологий. Если предприятие не готово провести необходимые организационные и управленческие изменения в бизнес-технологиях, пусть лучше работает по-старому. Автору пришлось непосредственно участвовать в прецеденте, когда разработанный усилиями сотрудников пяти отделов электронный архив, причем в двух программных реализациях, просто стал памятником автоматизации — на завершающем этапе работ руководство даже не удосужилось принять решение по выбору и внедрению системы. К сожалению, «закапывание денег« в автоматизацию стало повсеместным явлением. Чтобы изменить эту ситуацию, необходима реальная (а не декларативно-показная) заинтересованность и контроль высшего руководства предприятий над ИТ и деятельностью ИТ-служб, наличие сильных ИТ-руководителей и специалистов у предприятий, а также подрядчиков, предлагающих, прежде всего, честный и грамотный консалтинг, основанный на системных решениях, а не частные программно-технические комплексы.
Время «самостийного» выживания машиностроительных предприятий после постсоветского периода прошло. Предприятиям нужны новые модели и технологии сотрудничества, основанные, прежде всего, на взаимодействующих системах управления электронной технической документацией.
Михаил Головко () — независимый консультант по CALS-технологиям (Казань).

Документ в СЭД

Документ — основная единица информации, и все существование системы документооборота посвящено хранению документа, его свойств и истории его жизни, а также собственно обеспечению его жизнедеятельности.
В свое время в Microsoft ввели для всех файлов, сохраняемых своими офисными приложениями, стандартную шапку, в которой задавались бы свойства, такие, как заголовок и автор. Однако на практике эта возможность не прижилась; редкий документ содержит что-то осмысленное в разделе свойств. Не получил широкого применения и механизм сохранения различных версий документа в одном файле, реализованный в MS Office 2000. Причина проста: без системных организационных мер и единства подхода наличие частных механизмов в конкретных продуктах не дает результата. Очевидно, что такие средства, как описание атрибутов документа, сохранение его версий и т.д., должны быть поддержаны в рамках информационной среды безотносительно к типу документа и приложению, с помощью которого этот документ создан.
Документ — логическая единица. Способ его хранения зависит от того, как с ним удобнее работать. Ваш документ может состоять из текста, чертежей, рисунков и таблиц. Механизм COM позволяет организовать в одном файле подобие файловой системы, состоящей из аналогов папок и файлов. Этот механизм используется, например, в Word для того, чтобы обеспечить возможность вставки в текст объектов, созданных другими приложениями. Но это не всегда удобно; проще и практичнее хранить все части документа в отдельных файлах, каждый из которых редактируется своей программой. В большинстве СЭД отдельный документ может физически состоять из набора файлов.

Компоненты СЭД

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

Для организации хранилища карточек возможны три варианта решения: использование собственного хранилища, стандартной СУБД или средств среды, на основе которой построена СУБД.

Собственное хранилище атрибутов документов позволяет оптимизировать его под задачу хранения карточек, гибко реализовать функции создания сложных карточек (имеющих, например, большую вложенность типов), а также использовать эффективные алгоритмы поиска информации в карточках. К системам, имеющим собственное хранилище, относятся, например, Documentum, «Евфрат» компании Cognitive Technologies и «Гарант-Офис» компании «Гарант Интернейшнл». Очевидным недостатком такого подхода является невозможность использовать стандартные ресурсы имеющейся информационной среды, а также зависимость критически важной информации от поставщика СЭД. В случае, если вы используете стандартную СУБД, всегда есть возможность миграции данных на СУБД от другого поставщика. Здесь же выбор жестче — придется отказаться от использования конкретной СЭД вообще, а миграция данных из одной СЭД в другую на порядок сложнее, чем в случае СУБД.

При использовании стандартных СУБД для хранения документов данная проблема решается. К такого рода системам относятся, например, системы «Дело» от ЭОС, «1С:Архив» и DocsFusion компании Hummingbird. Однако такой подход имеет свои слабые стороны — реляционная модель, реализованная в большинстве СУБД, не удобна для модели данных, используемой в СЭД. Достаточно сложно обеспечить необходимую гибкость при создании карточек документов, особенно, если нужна сложная структура. Разработчики СЭД при этом оказываются перед дилеммой: разработать простую, но эффективную структуру хранения данных, при этом отказаться от гибкости при создании карточек, либо иметь громоздкую структуру, которая обеспечивает необходимую гибкость за счет эффективности, прозрачности и надежности работы системы. Вторая неприятная проблема состоит в том, что при использовании внешней СУБД возникают некоторые трудности как при миграции с одной версии СЭД на другую, так и при переходе с одной версии СУБД на другую.


Чаще всего такая ситуация приводит к определенному консерватизму пользователей в вопросе перехода на новые версии.

Если СЭД построена на основе какой-либо информационной среды, то грех не воспользоваться ее ресурсами. Большинство систем такого типа, популярных в России, построено на основе Lotus Notes/Domino. Это позволяет использовать все механизмы, заложенные в эту среду, в том числе средства резервного копирования, репликации, поиска и т.д. Проблемы такого подхода лежат в самой необходимости наличия определенной среды для работы системы управления документами, а также в тех ограничениях, которые накладывает конкретная среда на структуру ее баз данных.

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

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

При работе с файловой системой большинство СЭД требуют перемещения файлов в специально организованные каталоги.


Но есть и исключения. Например, системы «Евфрат» и Microsoft SharePoint позволяют регистрировать в системе файлы, не требуя их физического перемещения в хранилище. Понятно, что такой подход опасен с точки зрения целостности данных, но зато очень удобен в «переходный период» внедрения СЭД.

Системы, имеющие свое собственное хранилище файлов или использующие хранилище среды, на основе которой построены (например, Lotus Notes/Domino или Microsoft Exchange), могут гарантировать более эффективное управление доступом к документам и более надежное решение проблемы разграничения доступа. Так устроены, например, Documentum и системы на основе Lotus Notes («БОСС-Референт», CompanyMedia). Но при этом возникают вопросы, связанные с целостностью данных, наличием эффективных средств резервного копирования и интеграцией со средствами архивного хранения на медленных носителях. В большинстве систем они так или иначе решены, однако можно пользоваться только инструментами, доступными в самой системе, в то время как в случае файлового хранения вы всегда имеете выбор.

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

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

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

Маршрутизация и контроль исполнения. Обеспечивает доставку документов в рамках бизнес-процедур в организации.


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

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

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


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

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

Место СЭД в информационной системе предприятия

Основные функции СЭД: обеспечение управляемости и прозрачности деятельности предприятия, а также накопление знаний и управление знаниями. В современном мире эти две задачи становятся все более критическими. Например, в себестоимости автомобиля «Мерседес» лишь 30% — непосредственные издержки производства, а остальное — компенсация стоимости разработки автомобиля, т. е. стоимости деятельности инженеров и управленцев, поэтому в оптимизации их деятельности и лежит основной ресурс снижения себестоимости.
СЭД и другие Степень эффективности использования СЭД определяется тем, насколько документы (неструктурированная информация) определяют информационное наполнение деятельности предприятия. Очевидно, например, что для чисто торговой организации основное информационное наполнение — это структурированные данные, заключающиеся в базах данных. Возможно, такой организации и нужно хранить договоры, но вряд ли дело дойдет до внедрения СЭД. Однако если торговая организация дорастет до торгового монстра с сетью магазинов в десятках городов и сложной логистикой, собственным производством полуфабрикатов, то рано или поздно придется подумать о внедрении системы ERP. На следующем этапе количество оптовых покупателей и крупных заказчиков может вырасти до таких масштабов, что придется подумать о внедрении CRM. И только если при этом аппарат управления разрастется до сотни человек, появятся параллельные непрофильные проекты, возникнут задачи диверсификации, встанет задача внедрения СЭД. При этом какие-то системы, возможно, придется интегрировать, чтобы система CRM имела ссылки на письма, договоры и на копии входящих заказов, которые хранятся в СЭД.
В некоторых случаях интеграция этих систем еще более тесная — СЭД может служить интегрирующим транспортом для передачи документов между системами, которые их порождают, и системами, которые их потребляют, в случае, когда прямая связь на уровне структурированных данных между этими системами не нужна. Предположим, предприятие имеет системы CRM и ERP, причем требуется, чтобы в CRM фиксировались ежеквартальные отчеты из ERP о поставках товара конкретному клиенту, дополненные, возможно, комментариями экспертов.
Понятно, что такие отчеты удобнее всего хранить в СЭД. Благодаря интеграции ERP и СЭД документ будет автоматически создан и сохранен. Благодаря интеграции СЭД и CRM возможно автоматическое прикрепление документа к карточке конкретного клиента. И все эти операции могут происходить автоматически. (Подчеркнем, что приведенный пример является чисто умозрительным и на самом деле может не иметь практического смысла; интеграция любых информационных систем имеет смысл только тогда, когда четко понятна ее цель.)

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

Стандарты для систем управления документами

Стандартизация в области систем управления документами в основном заключается в выработке спецификаций взаимодействия систем от различных производителей, а также внешних приложений. Стандартизируются как сами протоколы, так и форматы данных, передаваемых между системами. На данный момент наиболее популярным универсальным стандартом взаимодействия с внешними приложениями (офисными приложениями, средствами потокового ввода) стал ODMA (). Этот стандарт существует с 1994 года, и его поддерживают многие производители ПО. Однако, как все универсальное, ODMA содержит определенные ограничения и всегда оказывается «запасным» вариантом взаимодействия с СЭД, когда, по какой-то причине, нет возможности реализовать более полноценную интеграцию. К примеру, несмотря на то, что начиная с версии Office 97 в продуктах Word и PowerPoint поддерживается ODMA, практически все производители СЭД поставляют специальные макросы для интеграции с MS Office.
Правда, есть случаи, когда протокол ODMA оказывается вполне эффективным. К примеру, система ABBYY FineReader, начиная с версии 4.0, поддерживает ODMA, что позволяет пользователю, не обращаясь к производителю СЭД или к услугам интегратора, вводить бумажные документы в хранилище систем, поддерживающих этот протокол. К сожалению, ODMA не затрагивает вопросов взаимодействия между различными СЭД, однако другие стандарты имеют существенно меньшее применение.

Технологии электронного документооборота

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

Тенденции

Очевидно, что функциональность систем управления документами в части решения вопросов управления практически полностью удовлетворяет сегодняшние запросы, и здесь особого развития в ближайшие годы не будет. Основное направление развития систем документооборота — повышение эффективности поиска информации, интеграция со средствами публикации информации в сетях, автоматическая сортировка и рубрикация документов.
Развитие систем управления документами получит второе дыхание с появлением средств, позволяющих осуществлять смысловой поиск информации и интеллектуальное автоматическое реферирование текстов на основе смысла. К сожалению, пока никто не может сказать, как быстро такие технологии станут коммерчески доступными.
Как утверждают эксперты, в плане внедрения систем электронного документооборота мы отстаем от стран Западной Европы примерно на 5 лет. Западный опыт показывает, что при массовом внедрении возникает спрос на весь спектр продуктов — от самых простых до сложных, распределенных и интегрированных решений. Поэтому у нас, похоже, в ближайшее время будет в большей степени превалировать тема внедрения уже имеющихся систем, нежели их дальнейшее развитие.
Арам Пахчанян () — вице-президент по корпоративным проектам компании ABBYY Software House (Москва).

Типовые требования к СЭД

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

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

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

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

поддерживать иерархию категорий для эффективного поиска документа;

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

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

поддерживать технологию HSM;

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

поддерживать удаленный доступ к информации. Продвинутые системы должны поддерживать:

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

территориально распределенные организации;

алгоритмы шифрования при хранении и передаче данных;

цифровую подпись. Требования к архитектуре:

наличие выделенного сервера приложений;

наличие тонкого клиента; поддержка доступа к документам с использованием браузера.

многоплатформность для обеспечения масштабируемости; Требования к открытости и интеграции с другими системами:

интеграция со средствами потокового ввода документов;

интеграция с офисными приложениями;

интеграция с электронной почтой;

наличие развитого программного интерфейса (API);

интеграция со стандартными службами каталогов (к примеру, LDAP) для ведения и синхронизации списка пользователей системы;

возможность адаптации пользовательского интерфейса под конкретные задачи;

возможность дополнения системы собственными специализированными компонентами; В случае использования внешней базы данных для хранения атрибутов документов необходимо наличие подробного описания структуры данных и средств работы с разными СУБД.

Жизненный цикл документа в СЭД

Рождение В один прекрасный день на свет появляется новый документ. Этот праздничный для документа день в современных системах хранения фиксируется и хранится, однако в стихии обычных файловых систем можно легко потерять предысторию файла. Достаточно, например, просто переписать на его место новый файл с тем же именем, и никто уже не вспомнит о предшественнике, не говоря уже о том, что файл, полученный из Сети, вообще не имеет «ни рода ни племени»: датой его создания всегда будет момент, когда он оказался на жестком диске вашего компьютера. В СЭД документ не может возникнуть, если у него нет «паспорта» — карточки учета, которая может быть разной для различных типов документов: документ нельзя просто так удалить, переименовать или переписать поверх. Все эти действия протоколируются, их следы останутся. В случае необходимости, система сохранит все предыдущие варианты и даже удаленные документы. Все действия, которые могут быть проделаны над документами, определяются правами, которые даны пользователям, что позволяет задать стратегию работы с документами.
Становление Любой документ непременно проходит этап своей жизни, который называется «черновиком» — неокрепший документ в этот период переходит из рук в руки, его меняют и переделывают. Качество результирующего документа во многом зависит от того, насколько успешно и организованно он прошел через эту «черную» полосу своей жизни. В СЭД для организации коллективной работы над документом применяется техника блокировки редактируемых документов («check-out, check-in»). Система берет на себя заботу о том, чтобы в каждый момент документ мог редактировать только один человек. Благодаря этому механизму исключается возможность того, что два сотрудника создадут у себя две локальные копии документа и одновременно внесут в него изменения. Когда в СЭД один из сотрудников забирает документ для редактирования, остальные увидят это и не смогут изменить документ до тех пор, пока первый не вернул его обратно. При этом возвращенному документу автоматически присваивается новый номер подверсии.
Прежняя подверсия документа сохраняется, ее можно открыть, посмотреть и редактировать. Все действия всех участников процесса документируются, поэтому никакой путаницы не возникнет.

Публикация Это день, ради которого документ создавался и доводился до ума. Публикация — это момент, после которого документ «умирает». Благодаря наличию механизма публикации вы можете быть уверены, что всегда будете иметь в электронном виде в точности то же самое, что было, например, подписано, или отправлено в печать, или выслано партнеру. А что если потребовалось что-то изменить в документе после публикации? Для этого на основе опубликованной версии создается новый вариант документа и начинается новый жизненный цикл. В различных системах эта функция поддержана по-разному. Где-то создается полностью новый документ, а где-то — просто новая версия.

Архивирование После публикации документ отправляется в электронный архив, где ему предстоит пробыть столько времени, сколько это предусмотрено распорядком вашей организации. Есть документы, которые хранятся вечно. Есть документы, которые нужно хранить несколько дней. Создание архива — задача непростая, зависящая от потребностей организации. Например, документы, к которым часто обращаются, нужно хранить на быстрых носителях, а неактуальные документы, которые редко используются, можно положить на менее дорогие, но медленные носители. Для решения таких задач применяются технологии управления иерархическим хранением HSM (Hierarchical Storage Management), которые создают из всевозможных разнородных средств хранения «виртуальную файловую систему» сколь угодно большого размера, при этом управляя переносом информации с одного носителя на другой. Базовые средства HSM были встроены в Windows 2000, однако существуют и другие технологии, обеспечивающие более сложную и эффективную функциональность. Таковыми являются, например, продукты серии DiskXtender компании Legato Systems, Tivoli Storage Manager, Veritas Storage Migrator и др.

Поддержка жизненного цикла в различных СЭД Практически все современные системы электронного документооборота поддерживают все этапы жизненного цикла документа.


Вопрос только в том, насколько полна эта поддержка. Перечислять СЭД, в которых та или иная функциональность не поддержана, задача неблагодарная: к моменту появления этой статьи может выйти новая версия, где эта функция уже имеется. Часть систем не поддерживает механизм блокировки редактируемых документов, что делает коллективную работу с документами невозможной. Есть системы, ориентированные на делопроизводство, и в них не реализовано эффективное хранение документов, а актуально выполнение всех процедур работы с документами, регламентированных существующими нормами. А сами документы могут лежать в папках в шкафу. Некоторые системы ориентированы на эффективную поддержку движения электронных документов внутри структуры, но при этом не имеют собственного электронного архива — хранилище, реализованное в этих системах, предназначено только для оперативного хранения документов в процессе их жизненного цикла. После опубликования документы выходят из системы и возвращаются в типовую для них среду хранения, например, в файловую систему. К такой системе можно «пристыковать» электронный архив, где сохраняется документ вместе с его историей и сопроводительной карточкой. Например, компания «Электронные Офисные Системы» предлагает состыковать свой продукт «Дело» с электронным архивом, созданным компанией на основе сервера «Кодекс-Intranet/Internet». Тот же самый сервер компании «Кодекс» применяет и компания «Гранит-Центр» в качестве электронного архива к своей системе «ГранДок». Прежние версии обеих систем поставлялись без электронного архива.

BI-интеграция.

Большинство корпораций уже вложили средства в BI-инструменты, технологии и приложения. К сожалению, решения о покупке часто принимались на уровне департаментов и подразделений, т.е. в ущерб более тщательной аналитической стратегии и тактике на уровне всего предприятия. В результате в подразделениях одной компании могут использоваться инструменты, технологии и приложения различных поставщиков, в которых задействованы различные модели данных, механизмы хранения, а также методы обмена информацией для анализа, осуществляемые с помощью различных входных и выходных интерфейсов.
По данным Gartner Group, эффективность вложений (ROI) и интегрированность в 2-3 раза выше у компаний, реализующих проекты Business Intelligence с использованием BI-оболочки.

Форматы и механизмы обмена данными и метаданными определяются с помощью следующих стандартов:

XML for Analysis (XML для анализа),

Java OLAP API (JOLAP),

общая метамодель хранилища (CWM – Common Warehouse Metamodel)

расширяемый язык бизнес-отчетности (XRBL – eXtensible Reporting Business Language). BI Web-сервисы, построенные на основе этих стандартов, упрощают интеграцию ERP/CRM/SCM систем, ETL-инструментов, Хранилищ данных, OLAP-серверов, а также средств создания отчетов и запросов.

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

По мере увеличения спроса на BI-инструменты IT-компании вынуждены его удовлетворять, создавая все новые и новые отчеты и аналитические приложения. Необходимы средства для создания централизованной BI-инфраструктуры, которая будет управляться и поддерживаться техническим персоналом таким образом, чтобы удовлетворить аналитическим потребностям бизнес-пользователей всех уровней.
Согласно исследованию консалтинговой организации Patricia Seybold Group мы находимся в начале нового этапа, на котором разработка и поставка программ станет более эффективной, так как Web-сервисы позволят организациям быстро компоновать приложения, комбинируя J2EE- и .NET-компоненты довольно простым и безболезненным способом.
При разработке приложений с помощью Web-сервисов существует несколько методов. Например, некоторые производители уже опубликовали программные интерфейсы приложений (API) (которые передают функциональность через XML и SOAP), остальные же – пока еще только разрабатывают такие интерфейсы. На более высоком уровне предоставляются наборы инструментальных средств разработки ПО (Software Development Kits - SDK) и интегрированные среды разработки (Integrated Development Environments - IDE), которые обеспечивают полный набор компонентов для дизайна, разработки, тестирования, отладки, сборки и поддержки BI Web-сервисов.
Библиотеки компонентов Web-сервисов, такие как ETL-процедуры для транзакционных ERP-, CRM- и SCM-систем, а также предопределенные шаблоны для моделей приложений и пользовательские отчеты для различных бизнес-отраслей должны ускорить процесс анализа и могут применяться бизнес-пользователями для быстрой сборки BI-решений. Наконец, Web-сервисы позволяют поставщикам Business Intelligence быстро обеспечивать нужную функциональность для каждой конкретной BI-функции, например для тонкого клиента или для доступа к информации через электронную таблицу, созданную на базе Web.

BI-сотрудничество.

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

Что такое Web-сервисы?

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

Здесь речь идет:

об использовании функциональности одного приложения в других за счет предоставления его программного интерфейса (Application Programming Interface - API);

о форматировании сообщений с помощью языка XML;

об активизации сервисов средствами простого протокола доступа к объектам (Simple Object Access Protocol - SOAP);

о публикации сервисов на языке WSDL (Web Services Description Language);

о локализации сервисов с помощью универсального стандарта предметного описания и интеграции (Universal Description Discovery and Integration - UDDI).

Почему нужно использовать Web-сервисы в BI?

Чтобы лучше понять, каким образом и где можно применять Web-сервисы в BI, рассмотрим тенденции, формирующие современный рынок BI-продуктов. Надо сказать, что в последнее время на рынке происходят некоторые коренные перемены, связанные с новым понятием, которое аналитическая корпорация Gartner Group называет управлением корпоративной эффективностью (CPM – Corporate Performance Management), ее конкуренты IDC (International Data Center) и META Group - управлением эффективностью бизнеса BPM – Business Performance Management), а независимая аналитическая фирма AMR Research– управлением коммерческой деятельностью предприятия (ECM –Enterprise Commerce Management). Вне зависимости от того, какой термин используется, важно понимать, что это не просто новые названия, а существенный сдвиг в отношении к Business Intelligence как к средству повышения эффективности деятельности компании.
 По прогнозам IDC, среднегодовой темп роста в сложных процентах (CAGR, Compound Annual Growth Rate) на рынке BI составит 29,6% и к 2005 году достигнет 11, 8 млн. долл.

Перечислим основные факторы, обуславливающие этот рост:

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

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

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

Пример BI Web-сервисов

Рассмотрим, как BI Web-сервисы могут принести существенную пользу для бизнеса.
Правильная оценка спроса особенно важна для сохранения рентабельности в розничной торговле и в продаже потребительских товаров. Согласно исследованию AMR, выигрыш за счет сбора информации о спросе в торговых точках и последующего ее использования при управлении цепочкой поставок может сократить недостаток или избыток складских запасов на 50%.
Одна из сложнейших проблем, с которыми сталкиваются компании, работающие в сфере развлечений и распространяющих видеокассеты в точках розничной торговли, состоит в необходимости точного планирования продаж и управления складскими запасами на уровне отдельных розничных магазинов. По оценкам одной из компаний, 50% продаж видеокассет приходится на первые четыре недели после выпуска и 80% – на первые десять недель. Соответственно, минимизировав недостаток товаров, можно максимально повысить доход от продаж новых выпусков. Но заниматься массовым выпуском и продажей продукции видео фирмы не могут, так как их доходы резко сокращаются от перезагруженности складов и расходов на распространение.
В этом примере компания использует BI-инструменты, чтобы оценить эффективность влияния различных маркетинговых программ на продажу видео и лучше выявить закономерности спроса, их связь с продуктами и их продвижением. Фирма анализирует статистику влияния рекламных акций на продажу видео-продукции в зависимости от различных параметров, как-то: категория (комедия, драма, детские фильмы), язык/география, тип носителя (VHS, DVD). Затем на основе этой информации определяют, какие маркетинговые мероприятия необходимо провести в том или ином сегменте рынка для новых выпусков. Зная влияние программ продвижения на продажи, можно точнее прогнозировать спрос.
На этом основные задачи компании, казалось бы, исчерпаны, однако работа найдется и для Web-сервисов. Например, пока еще непросто осуществлять заблаговременный сбор данных в согласованном формате о материальных запасах со всех точек розничной торговли (для того чтобы осталось достаточно времени на выпуск и распространение продукции для пополнения складов).
В данном случае очевидна ценность BI Web-сервиса, который сможет выступать в качестве интеллектуального агента, выполняющего мониторинг бизнес-операций на уровне розничного магазина, преобразующего данные в стандартный формат и посылающего предупреждения о выполнении заданных условий или достижении пороговых значений.
Просмотрев последний черновик этой статьи, автор задумался: а не попал ли он на рекламную удочку? Тогда было решено проконсультироваться у коллег - инженеров и обслуживающего персонала, сведущих в вопросах практического применения BI. Вопрос стоял так: «Обоснованно ли я описываю потенциал Web-сервисов или предлагаю вымышленную BI-панацею?»
Коллеги подтвердили, что представленная здесь точка зрения вполне обоснована, но с той оговоркой, что прежде, чем мечта станет реальностью, нужно решить еще несколько вопросов. Например, для успеха BI Web-сервисов ключевую рoль играют отраслевые стандарты, но в настоящее время лишь немногие производители гарантируют соответствие своих продуктов таким стандартам, как CWM, XML for Analysis, JOLAP и XRBL. Более того, Microsoft и Oracle до сих пор не могут принять соглашение по единому OLAP API, что могло бы ускорить широкое распространение BI и развитие управления эффективностью бизнеса.
Один из коллег провел такую аналогию. До сегодняшнего дня компании использовали Web-средства Business Intelligence для создания аналитической инфраструктуры, являющейся основой управления эффективностью бизнеса. Однако построения такой инфраструктуры недостаточно – это все равно, что сделать машину без зажигания. У нее будет и мотор, и колеса, и руль, но с места она не сдвинется. Таким образом, Web-сервисы дают ключ к старту механизма управления эффективностью бизнеса, который поможет быстрее повысить доходность.

Chief Financial Officer CFO Chief Information Officer

Web-сервисы на службе у Business Intelligence

Дата: Май 2003 года
Автор: Дэн Эверет (Dan Everett)
Перевод: Intersoft Lab Внедрение Web-технологий в Business Intelligence – идея не новая: уже много лет компании пользуются языком HTML (hypertext markup language – язык разметки гипертекстовых файлов) в качестве недорогого и относительно простого способа распространения статической информации в виде постоянного формата отчетности. Однако при этом возникают сложности, связанные с особенностями протокола (HTTP) передачи HTML-файлов, который не предусматривает запоминания предшествующих состояний и не поддерживает постоянных соединений, что необходимо для нерегламентируемого анализа.
Для решения этой проблемы, производители BI-инструментов обратились к технологиям Java и ActiveX, позволяющим существенно расширить функции HTML. Это, с одной стороны, позволило обеспечить более сложные возможности интерактивного анализа. Но с другой стороны, из-за существенного увеличения объема информации, загружаемой Web-браузером, остро встал вопрос о пропускной способности сети и скорости соединения. Кроме того, эти технологии поддерживают не все платформы и браузеры.
Сейчас появляются более функциональные и надежные подходы к реализации BI в Web. Предлагается использовать программные компоненты на основе технологий DCOM (Distributed Common Object Model - Распределенная модель компонентных объектов) и .NET фирмы Microsoft, а также архитектуры CORBA Common Object Request Broker Architecture – Обобщенная архитектура обработчика объектных запросов) и технологии EJB (Enterprise Java Beans), реализованной на платформе J2EE (Java 2 Enterprise Edition). Эти компоненты применяются при создании Web-сервисов промежуточного уровня (middle-tier) между HTTP-сервером и базой данных, управляют обработкой соединений с базой и логикой приложения, устраняя необходимость загрузки и обработки кода на клиенте.
Также важно отметить, что программный компонент промежуточного уровня - это не просто звено, а часть многоуровневой архитектуры приложения. Использование такой архитектуры сокращает временные и материальные затраты, необходимые для распространения приложений и балансировки нагрузки между новыми серверами по мере роста количества пользователей. Для конечных пользователей эта технология обеспечивает более быстрый, согласованный и надежный доступ к необходимой информации.

Анализ бизнес-процессов

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

Автоматизация бизнес-процессов

И.М. Слюсаренко, М.Ю Слюсаренко, «InfoSoftCom»

Алексей Телековский

Евгений Патий

Алексей Прошин, директор по инструментальным средствам описания бизнес-процессов компании «ФОРС — Центр разработки»

Ольга Бурносова, консультант
Департамент консалтинга компании «Ай-Теко»

В.Сенкевич, Управляющий директор PayBot LLC

Уильям Батерст,

С.Битюков, старший консультант Oracle СНГ
Источник:

Bhagat Nainani, перевод

Подготовлено Intersoft Lab по материалам зарубежных сайтов

по материалам зарубежных сайтов ,

, старший редактор издательства Oracle Publishing.
Перевод Oracle Magazine RE

Ольга Дубина , Источник:

Александр Шарцев, Зам. начальника управления информационных технологий и систем ООО "ЛУКОЙЛ-Бурение-Пермь"

(Rich Schwerin), старший редактор издательства Oracle Publishing

Владимир Андреев, менеджер по продукции компании Digital Design
IT Manager #6(12)/2003

- менеджер проектов

Маргарита Моисеева,

,

,

Александр Глинских (к.т.н.),

Автоматизация сквозных бизнес-процессов предприятий с использованием BPEL

С.Битюков, старший консультант Oracle СНГ
Источник: 12 Октябрь 2005 г Как получается, что организация работает? Почему в результате действий большого количества людей, документооборота, накопления и преобразования данных в информационных системах в конечном итоге получается тот самый результат, который ожидается? Как помыслить о том, что происходит в организации, в достаточно абстрактных и простых терминах и не уходя при этом слишком далеко от реальности?
Бизнес-процесс – одна из концепций, которая предназначена именно для этого. Кстати, существуют и другие термины, обозначающие то же самое, но в некоторых особых видах человеческой деятельности. Например, в государственном и муниципальном управлении принято говорить о регламентах, в том числе электронных, однако мы будем далее говорить о бизнес-процессах как о понятии, наиболее часто используемом в литературе, в первую очередь англоязычной. Можно по-разному определять, что же это такое (и на таком произволе и образуются различные школы и методики), однако важно то, что бизнес-процесс представляет собой некоторое действие, состоящее из более мелких действий, связанных между собой некоторым образом, и зафиксированное некоторым формальным способом. Формализация очень важна, потому что как только она появляется, то вместе с ней приходит возможность применять весь аппарат работы с формальными системами – то есть средства анализа, моделирования, верификации и много чего ещё.
Вокруг этой идей возникла целая индустрия BPM – моделирования бизнес-процессов, Business Process Modeling. Много решений пришло на возникший таким образом рынок, и остались наиболее удачные. И так бы продолжалось и далее, но постепенно стало понятно, что моделирование - это, конечно, тоже важно, но между аналитиком, который рисует диаграммы (так как хорошо известно, что человеку удобнее работать с образами) и программистом, который на основе этих диаграмм осуществляет непосредственное программирование самих процессов, существует некоторая дистанция, преодоление которой неизбежно связано с ошибками – как вследствие простой невнимательности, так и обусловленной различием представлений программиста и аналитика о семантике используемой в диаграммах нотации и, соответственно, придаваемому диаграммам смыслу.
Отладка также непроста, но что самое неприятное, происходит постепенное – по мере разработки систем – рассогласование диаграмм и их реализаций.

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

Особенно на Западе, автоматизация предприятий велась давно. По мере совершенствования технологий оказывалось, что та или иная задача наконец-то может быть автоматизирована. Так автоматизировались всё более и более сложные части – и, наконец, количество начало переходить самым диалектическим образом в качество, и появилась возможность автоматизировать сквозные бизнес-процессы, то есть, фактически, автоматизировать целые функции предприятий. Но тут же выяснилась и главная трудность – системы-то разные, и многие из них весьма древние, унаследованные. А значит, именно интеграционная работа начинает выходить на первый план. Традиционные же Workflow-системы на интеграцию в большинстве своём не ориентированы.

В рамках архитектуры SOA любая система представляется как набор сервисов – однако такие сервисы не обязаны быть SOAP-ориентированными WEB-сервисами. Многие сервисы бывает просто нецелесообразно представлять в таком виде – например, когда происходит обмен большими объёмами данных, то передача их по протоколу SOAP будет подразумевать их представление в виде XML, то есть не только расходы процессорного времени на его обработку, но и, что много хуже, существенно большую нагрузку на каналы связи. Для таких сервисов реализуются специализированные адаптеры – например, адаптеры доступа к файлам, базам данных, ERP-системам, и многим другим информационным ресурсам. Впрочем, существуют стандарты разработки адаптеров “вообще” - например, JCA (Java Connector Architecture), и эти стандарты обычно поддерживаются BPEL-средствами.


Реализовать несколько сот связей между полутора дюжинами “островками автоматизации” - это не под силу знаменитому Average Joe, даже если он будет трудиться по ночам и выходным. Однако эту проблему решили в рамках архитектуры SOA (Service-Oriented Architecture), в рамках концепции единой информационной шины, что позволяет сократить число связей. Впрочем, эта проблема – не единственная, которая решается в рамках архитектуры SOA.

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

Похожим образом рассуждали аналитики крупнейших компаний IT-индустрии, когда вели разработки и принимали различные стандарты описания бизнес-процессов. Некоторые стандарты были более удачными, некоторые – менее, однако именно по BPEL (более точно, BPEL4WS 1.1) индустрия достигла широкого консенсуса. BPEL “выстрелил” - появился совершенно новый рынок – рынок BPEL-ориентированных интеграционных средств.

BPEL – это не только могучее средство интеграции, но также и алгоритмически полный язык, система типов которого – это система типов XML; язык с весьма выразительными управляющими конструкциями, поддержкой параллельного исполнения, детальной обработкой исключений, поддержкой транзакций, взаимодействия процессов между собой и много чем ещё. Однако при всём при том BPEL довольно сильно ограничивает аналитика в некоторых вещах. Грубо говоря, BPEL не позволяет осуществить произвольную передачу управления внутри бизнес-процесса – нарисовать “стрелку-переход” между любыми двумя “квадратиками”, изображающими простые действия. В этом ограничении есть определённый смысл.

Ещё на заре развития программирования стало понятно, что идея произвольного перехода в программе является порочной.


Дейкстра выдвинул тезис о необходимости так называемого “структурного программирования”, то есть, фактически, отказа от использования оператора произвольного перехода GOTO в пользу циклов. Эта идея оказалась плодотворной, и с тех пор все основные языки программирования высокого уровня её реализуют. Настолько радикальным зачастую бывает представление о вреде GOTO, что язык попросту не содержит такой конструкции.

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

Бизнес-процессы могут подразумевать взаимодействие не только с информационными системами, но и с людьми. Более того, наивное представление о бизнес-процессах вообще не подразумевает ничего иного, кроме людей. Поэтому поддержка так называемых “human workflow”, то есть таких бизнес-процессов, которые бы описывали информационное взаимодействие именно между людьми, чрезвычайно важна.

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


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

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

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

Неудивительно поэтому, первые успешные внедрения BPEL оказались именно в сфере телекоммуникаций и финансов.

Компания Oracle предлагает готовое BPEL-ориентированное интеграционное решение Oracle BPEL Process Manager 10g. В состав этого решения входит средство разработки на базе Oralce JDeveloper 10g и сервер, который сам существует в двух вариантах. Первый вариант – для разработчиков, основан на Oracle Containers for Java (OC4J) и базе данных Oracle Lite.


Второй вариант – для промышленного использования, исполняется под управлением Oracle Application Server 10g и СУБД Oracle 10g. Кроме того, в поставку входит Worklist Application и BPEL Console. Последнее приложение предназначено для управлением процессами в реальном времени, их аудита и контроля. См.

Исторически, это решение разрабатывалось независимой компанией Collaxa, которая впоследствии была приобретена. С тех пор решение сохранило ряд довольно полезных свойств, которые включают в себя независимость от сервера приложений (Oracle BPEL Process Manager может функционировать под управлением, например, JBoss и BEA Weblogic, а также некоторых других), а также специализированный plug-in для среды разработки с открытым исходным кодом Eclipse 3.0. В целом, можно ожидать, что индустрию BPEL-ориентированной интеграции ждёт большое будущее. Выгоды, которые получают предприятия от внедрения описанной технологии, весьма значительны – даже если относиться с некоторой долей скепсиса к её глобализационным перспективам – поскольку такие возможности как автоматизация партнёрских отношений, реализация композитных услуг являются важными конкурентными преимуществами, которые получают предприятия, внедряющие данную технологию. Для организаций государственного и муниципального управления внедрение данной технологии является частью реализации концепции электронного правительства.

II. Моделирование процессов с применением BPMN

В качестве стандарта для моделирования бизнес-процессов получает признание BPMN (Business Process Modeling Notation - нотация моделирования бизнес-процессов), разработанная организацией Business Process Modeling Initiative (BPME.org). Основное назначение BPMN заключается в предоставлении нотации, легкой в использовании и понимании для бизнес-пользователей, включая бизнес-аналитиков, моделирующих бизнес-процессы, технических разработчиков, которые создают системы для выполнения этих процессов, и менеджеров различных уровней, которые должны быстро читать и понимать процессные диаграммы, чтобы принимать деловые решения.
BPMN напрямую отображается на языки исполнения бизнес-процессов, такие как BPEL и BPML. BPMN предоставляет нотацию для моделирования, а BPEL является языком описания исполнения процессов.
К ключевым особенностям BPMN относятся:

Пулы и лейны (Pools and lanes - бассейны и дорожки) — эти сущности используются для демаркации процессов и систем. Пул используется, чтобы разделить различные бизнес-сущности или участников. Действия (activities) внутри пулов – это модульные (self-contained) процессы. Лейны (Lanes) используются для описания и разделения действий в пулах (как бы водные дорожки в бассейне – прим.ред). Они, как правило, используются для группирования действий по функциям или ролям.

События и действия (Events and activities) — События используются для представления того, что происходит в процессе бизнес-деятельности. У этих событий обычно есть причины/эффекты (следствия), и они могут влиять на сам поток. Действия ссылаются на работу, которая исполняется, либо как единая задача, либо как набор задач (подпроцесс).

Соединенные объекты (Connect objects) — различные сущности BPMN могут быть соединены через последовательность операций, поток операций (sequence flow), чтобы отметить порядок, в котором действия выполняются, поток сообщений, чтобы отметить сообщения между сущностями, или ассоциацию, используемую для ассоциирования текста и других артифактов с объектами потока (flow objects).

Проектирование сложного процесса (Complex process design) - BPMN может использоваться, как для высокоуровневого описания процессов, так и для описания сложных процессов со многими уровнями детализации.
Процессы могут включать детализирующие представления (drill down views) для описания деталей более низкого уровня (lower levels of detail) внутри отдельных диаграмм.

Моделирование и контроль сообщений (Model message and control) — в дополнение к спецификации порядка операций в потоке BPMN обеспечивает представление об объектах данных для моделирования того, как документы, данные и другие объекты используются и изменяются во время процессного потока.

BPMN предоставляет нотацию моделирования, которая обеспечивает переход от бизнес-определений к карте исполнения процесса (process execution map). Объекты BPMN обладают богатым набором атрибутов, которые позволяют легко отображать эти объекты в описания BPEL, стандарт defacto для исполнения процессов.

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

Рассмотрим пример процесса LoanFlow (), который используется типичным брокером займов (loan broker). Этот брокер займов принимает запрос от клиента, выполняет кредитную проверку (credit check) с обращением к внешней службе и затем направляет это прошение к двум различным агентствам по предоставлению займов (loan agencies). После получения предложений от них лучшее будет отобрано и клиент будет уведомлен об этом.

На этапе моделирования обычно специфицируются участники (LoanBroker, CreditRating service, StarLoanService, UnitedLoanService и клиент). Процесс LoanFlow оркестрирует взаимодействия между этими сервисами. Для этого необходимо специфицировать последовательность событий и поток сообщений между этими сущностями, используя BPMN. иллюстрирует высокоуровневую модель процесса в BPMN и детализацию для подмножества этого процесса, когда соответствующий менеджер (loan offer) обращается к двум различным агентствам по предоставлению займов.

III. Имитация и анализ

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

Время (период времени), необходимое для исполнения, и цена каждого действия

Определены нужные для каждой задачи ресурсы

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

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

Вычислить среднее (average elapsed) время транзакции, полную, от начала до конца (end-to-end) пропускную способность и стандартные отклонения (deviation) для определения того, насколько эти отклонения соответствуют допустимым по соглашениям об уровне обслуживания SLA (Service Level Agreements);

Идентифицировать “узкие места” при использовании процесса и ресурсов;

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

Вычислить ожидаемые оценки ошибок и рейтинги уровней обслуживания по 6 сигма (six sigma);

Определение оптимизации, необходимой для перехода процесса на уровень “как должно быть”;

Продолжая пример LoanFlow из Секции II, можно смоделировать режим заполнения и время обработки прошений о займе для каждого агентства, о предоставлении займов, а затем “прогнать” имитацию, чтобы оценить пропускную способность или время ответа для сквозного потока. Также, если мы предположим, что есть некоторое, достаточное для выполнения этой задачи, количество агентов по займам в StarLoan и UnitedLoan, и мы зададим некоторое среднее время для обработки прошения о займе, то имитация поможет определить использование ресурсов и число нужных ресурсов на основе ожидаемых запросов на займы.

Интеграция OWSM и BPEL

Уильям Батерст,
27 Октябрь 2005 г Источник: сайт Oracle Java Newsletter, август 2005,

IV. Документирование и внедрение

Во время этого этапа высокоуровневая модель процесса преобразуется в модель исполняемого процесса. До автоматизации процесса он, как правило, документируется в форме, которая может быть использована персоналом и партнерами. Этот документ включает информацию, которая определяет поток бизнес-процесса (business process flow), роли вовлеченных сущностей, исключительные ситуации, ожидания и требования к ресурсам. Все это нужно для будущей поддержки и улучшения процесса. И это также может помочь в достижении соответствия некоторым требованиям регулирующих органов. Следующий после документирования шаг – это внедрение бизнес-процессов. Язык BPEL (Business Process Execution Language) становится очевидным стандартом внедрения для объединения множества синхронных и асинхронных сервисов в коллективные (collaborative) потоки и транзакции. При разработке BPEL воспользовались результатами более чем десяти исследований его предшественников – языков XLANG и WSFL. Он включает следующие концепции:

Web Services/WSDL - как компонентная модель

XML - как модель данных

Шаблоны синхронного и асинхронного обмена сообщениями

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

Иерархическое управление исключительными ситуациями

Долгоживущая единица работы/компенсации (Long-running unit of work/compensation)

Oracle BPEL Designer предоставляет графический и дружественный интерфейс для построения BPEL-процессов. Что выделяет Oracle BPEL Designer – так то, что BPEL – это его “родной” формат. Это означает, что процессы, построенные с применением этого инструмента, 100% переносимы, и, кроме того, он позволяет разработчикам просматривать и модифицировать исходный код на BPEL, не снижая полезности этого инструмента. Если высокоуровневый процесс смоделирован на BPMN, он прежде всего экспортируется к скелетному (skeletal) BPEL-процессу, который как правило, состоит из областей действия процесса (process scopes), действий по вызову/получению (invoke/receive activities) и партнерских связей к соответствующим сервисам (partner links to the appropriate services).
Следующие шаги должны быть выполнены в Oracle BPEL Designer, прежде чем данный процесс может быть развернут:

Идентифицирование операций web-сервисов, которые вызываются различными сервисами;

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

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

Специфицирование положения конечных точек (endpoint) и параметров соединения для вовлеченных сервисов.

Если мы рассмотрим пример LoanFlow, описанный ранее, то для кода на BPEL, сгенерированного из средства моделирования BPMN, потребуется включение URL для этих сервисов, XSD для прошения об займе и предложения займа, а также определение трансформаций данных между документами, которые передаются между сервисами. показывает процесс LoanFlow, смоделированный в Oracle BPEL Designer.

IX. Заключение

BPM-системы полного цикла критичны для разработки эффективных бизнес-процессов, которые должны быстро реагировать на изменяющиеся бизнес-условия. Oracle AS Integration – это в настоящее время наиболее полная BPM-платформа на рынке. Она обеспечивает реализацию всего жизненного цикла процесса, включая моделирование, имитацию, внедрение, исполнение, мониторинг и оптимизацию бизнес-процессов.

А Вы попробуйте без Goto

litnimах, Сбт 09 Фев 2008 14:16:15: > Споры о GoTo ведуться давно
А Вы попробуйте без Goto смоделировать шаблон Arbitrary Cycles - http://www.workflowpatterns.com/patterns/control/structural/wcp10.php Litnimах, Срд 30 Янв 2008 14:36:52: > В частности, меня например напрягает накручивать сложное переплетение из IDEF и UML
А не надо это делать. Смотрите BPMN, и открытый продукт Intalio BPMS designer.
Не сказано по-моему, главное - BPEL - самодостаточный язык очень высокого уровня, бизнес-уровня. Он не нуждается в других языках, реализующих интерфейсы низкого уровня. Связка BPMN + BPEL позволяет разворачивать реальную сквозную автоматизацию, не прототип, прямо на глазах у менеджеров в процессе описания модели. Кирилл, Втр 29 Май 2007 16:37:03: 2аноним
UML в рамках RUP применяется в том числе и для описания бизнес-процессов.
А в чём уникальность BPEL я уже и сам вразумел. Это очередная парадигма отображения бизнес-процессов -- в данном случае сервисо-ориентированная. В этом смысле BPEL конечно интересен. Но ничего не ясно как люди могут включаться в процесс. Все примитивы BPEL касаются только сервисов и их взаимодействий, но нет и намёка на людей, исполнительные механизмы, различные хранилища данных. Можно конечно и человека как сервис включить в модель :) Хотя возможно я пока слишком поверхносно познакомился с возможностями методики. Но уже ясно одно -- BPEL не является универсальным решением. В частности, меня например напрягает накручивать сложное переплетение из IDEF и UML, к тому всё равно в конце концов возникают проблемы взаимодействия с реляционными БД. Я думал BPEL позволяет всё это делать в рамках единой методологии. аноним, Втр 29 Май 2007 16:10:59: >>В чём вообще уникальность BPEL?
>>Чем плохи традиционные старые методы
>>бизнес-моделирования (IDEF разные, UML)?

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

BPEL - Bisness Process Execution Language
у IBM используется в сервисно-ориентированной архитектуре SOA

а UML вообще-то совсем для другого - для визуального моделирования разработки софта применяется

>когда происходит обмен большими объёмами данных,
>то передача их по протоколу SOAP будет
>подразумевать их представление в виде XML, то
>есть не только расходы процессорного времени на
>его обработку, но и, что много хуже, существенно
>большую нагрузку на каналы связи.

не совсем так, зависит от того, как представляются данные Кирилл, Пнд 28 Май 2007 12:39:57: Складывается впечатление, что очередная пурга, написанная автором для повышения количества статей. О BPEL вообще ничего нет. В чём вообще уникальность BPEL? Чем плохи традиционные старые методы бизнес-моделирования (IDEF разные, UML)? Как решаются в рамках BPEL проблема объектно-ориентированного маппинга? Max, Вск 27 Май 2007 19:45:59: Споры о GoTo ведуться давно. И однобоко представлять, что изгнание этого механизма из ЯП это неоспоримое благо. Можно привести множество аргументов за GoTo. Вывод: не GoTo, а догматизация или демонизация его есть вред. Кроме того, спорна и сама концепция Дейкстра с его структурным программированием. Ведь там в угоду простоте выплескивают вместе с "водой" и "ребенка" - душу программирования - работу с именами, в частности вычислимыми.
Далее. Если уж говорить о вреде произвольного перехода, то операции циклирования не менее вредны. Ведь они изначально ориентированы на "замкнутость в актуальностях", т.е. на абсолютную централизацию - когда и сама операция циклирования и "тело цикла" выполняются на одном узле. Сегодня же догматизировать это - значит закрывать глаза на распределенность. Интересно, что в этом отношении сделано в Oracle BPEL? Какие модели применяются? Насколько данный продукт сохраняет инвестиции в него вложенные? Беренцев Антон, Чтв 10 Май 2007 10:31:53: Хороша в качестве введения. Легко и доступно читается. Хотелось бы больше конкретики по Oracle BPEL.

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

Bhagat Nainani, перевод 12 Октябрь 2005 г Оригинал: , An Oracle White Paper, ноябрь 2004

V. Развертывание и исполнение

Наиболее критичным этапом в жизненном цикле процесса является его развертывание на платформе, которая может оркестрировать поток и выполнять различные задачи этого процесса. Оркестрирование набора сервисов в сквозной поток процесса требует выполнения множества технических требований, включая соединение (binding) с разнородными системами, шаблоны для синхронного и асинхронного обмена сообщениями, манипулирование данными, координация в потоке, управление исключительными ситуациями, недетерминированные события, компенсирующие транзакции (compensating transactions), управление версиями, и т.д. Назначение стандарта BPEL – обеспечение более богатого, но в то же время более простого уровня абстракции/стандарта для удовлетворения этих требований. Продукт Oracle BPEL Process Manager обеспечивает наиболее зрелую, масштабируемую и полную реализацию механизма исполнения BPEL, доступную сегодня. Некоторые из ключевых функций этого сервера:

Поддержка стандартов — механизм включает непосредственную поддержку стандартов BPEL и web-сервисов;

Производительность и масштабируемость – высокопроизводительный BPEL-механизм исполняет одновременно множество BPEL-процессов и обеспечивает возможность “отжимки” ("dehydration"), так что состояние долгоживущих потоков автоматически поддерживается в базе данных. Возможно применение кластеров для обеспечения масштабируемости и отказоустойчивости;

Продвинутые функции – другие важные функции включают автономную работу с версиями, секционирование процесса и продвинутое управление исключительными ситуациями;

Множество платформ развертывания - BPEL Server использует OC4J как базовый J2EE-сервер приложений с поддержкой большинства основных коммерческих серверов приложений;

Встроенные сервисы интеграции — они позволяют использовать продвинутые возможности соединений и трансформаций из стандартного BPEL-процесса. Эти возможности включают поддержку для трансформаций и соединений с использованием механизма XSLT/Xquery, а также множества тиражируемых приложений и унаследованных систем . Расширяемая схема соединения WSDL обеспечивает соединения по протоколам и форматам сообщений, другим нежели SOAP. Соединения доступны для JMS, электронной почты, JCA, HTTP и многих других протоколов для связи с сотнями внутренних (back-end) систем.

Сервис пользовательской задачи (User task service), предоставляется как встроенный BPEL-сервис для обеспечения интеграции людей и выполняемых ими вручную задач в BPEL-потоки.

BPEL Console предоставляет web-интерфейс для управления, администрирования и отладки процессов, развернутых на BPEL-сервере. Автоматически поддерживаются данные аудита и информация истории процесса и отчетов, и все это доступно через BPEL Console и Java API.

На показана архитектура BPEL Process Manager и сопутствующих компонентов.

VI. Мониторинг

Измерение ключевых метрик процессов и “видимость” (visibility) в реальном времени исполнения процессов критичны для оценки производительности развернутых бизнес-процессов. Oracle Business Activity Monitoring (BAM) – это критичный компонент нашего полного BPM-решения. BPEL-процессы могут быть инструментированы с датчиками (sensors), чтобы осуществлять мониторинг критических действий и переменных. BAM позволяет соединять эти индивидуальные метрики в составные события. Панель BAM позволяет реализовать мониторинг, анализировать и своевременно отвечать на события или исключительные ситуации, которые происходят внутри предприятия.
Ключевые концепции Oracle BAM таковы:

Бизнес-события (Business Events) – перехват таких интересных событий как изменение информации о клиентах, изменения в описи товаров, заказах на покупку из широкого ряда информационных систем предприятия (EIS).

Составные события (Composite events) – определение, агрегирование, соотнесение и фильтрация событий от различных конечных систем.

Метрики и ключевые индикаторы эффективности (КПЭ или KPI) – выполнение сложной обработки составных событий для генерации метрик и КАЭ.

Сигналы (Alerts) – уведомление пользователей через различные каналы (электронная почта, голосовая почта, пэйджеры,..) на основе превышения пороговых значений и/или порогов рисков для некоторых ключевых метрик.

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

См.
Продолжим наш пример с LoanFlow из Секции II . После того, как процесс развернут, BAM-панель может быть использована, чтобы ответить на критические бизнес-вопросы:

(a) Запросы на займы, предоставленные сегодня, на этой неделе, в этом месяце.

(b) Предложения займов по агентствам

(c) Среднее время обработки одного займа

(d) средняя кредитная оценка (скоринг) лиц, желающих получить заем.

Также BAM-панель может отобразить сигналы:

(a) были предоставлены займы многим лицам с низкой скоринговой оценкой

(b) процент отвергнутых прошений о займах больше 10%.

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

VII. Оптимизация и перепроектирование

BAM закрывает отсутствующее звено между исполнением процесса и перепроектированием. Традиционно имитация процессов основана на предположениях и догадках. Проблема такого подхода в том, что надежны только результаты, а предположения делались на этапе моделирования. При применении BAM, как данные реального времени, так и исторические данные, накопленные за период времени, могут быть использованы, чтобы промоделировать процесс “как есть” (“as-is”) и создать оптимальный процесс “как должно быть” ("to-be"). Благодаря таким успешным итерациям процесс может быть тонко настроен, что приведет к значительной экономии ресурсов и средств. События в BAM также могут быть использованы для оптимизации развернутых процессе в реальном времени, благодаря изменениям потока бизнес-процесса. Сигналы (alerts) BAM также могут начать новые бизнес-процессы для обработки исключительных ситуаций или быть использованы для прерываний процессов.
Еще раз рассмотрим пример LoanFlow. На этапе оптимизации должны использоваться данные реальной обработки на основе ежедневных/ежемесячных отчетов и затем прогоны инструмента имитации для обнаружения возможных узких мест и уровней обслуживания (predict SLA). Это может привести к перепроектированию процесса. Например, к добавлению новых сервисов при оформлении займа, что соответствовать требованиям по времени ответ. Некоторые из этих метрик также могут использоваться в реальном масштабе времени. Например, если какое-то из агентств слишком долго не отвечает, процесс может продолжать работу только с одним предложением займа (применительно к одному агентству), чтобы удовлетворить SLA-требованиям обслуживания.

VIII. Партнеры

Корпорация Oracle установила партнерские отношения с рядом поставщиков, чтобы предоставить средства моделирования и имитации вместе с Oracle BPEL Process Manager и инструментом Oracle Business Activity Monitoring. В число этих поставщиков входят Popkin Systems and Software Ltd () — продукты Popkin System Architect и Popkin Simulator II могут быть использованы для моделирования и анализа процессов. При этом применяется BPMN и экспорт в формате BPEL для развертывания на платформе Oracle. За более подробной информацией о моделировании процессов с использованием этих средств, их внедрении и развертывании с Oracle BPEL Process Manager, обращайтесь по адресу

Защита потоков BPEL-процессов

Одной из возможностей Oracle Web Service Manager Оракула является способность защитить потоки BPEL-процессов. OWSM защищает BPEL, используя PEP (Gateway Policy Enforcement Point – Шлюзовая точка претворения политики), в который перехватываются SOAP-запросы и выдаются ответы в различные точки BPEL-процесса. Даайте рассмотрим демонстрационный пример Loanflow, приведенный в учебнике BPEL 101 Tutorial, чтобы проиллюстрировать, как OWSM защищает BPEL-процессы. BPEL-пример Loanflow демонстрирует автоматическое получение банковской ссуды:

Заявитель представляет банку на рассмотрение свою заявку.

Банк проводит кредитную проверку заявителя ссуды и получает оценку его кредитоспособности.

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

В этом демонстрационном примере “оценка кредитоспособности” - синхронный Web-сервис. BPEL-процесс будет ждать ответ от этого кредитного сервиса перед переходом к следующим шагам. Затем демо-пример начинает параллельный диалог с двумя асинхронными сервисами обработки ссуд (Star Loan и United Loan).
Диаграмма 1. Демонстрационный BPEL-пример Loanflow
Этот сценарий интересен тем, что в нем смоделирован бизнес-процесс, который обращается с конъюнктурные данными (например, номер [карточки] социального обеспечения), но этот бизнес-процесс не защищен. Мы же видим, что:

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

Номер Social Security ([карточки] социального обеспечения) заявителя представлен в открытом коде.

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

К BPEL web-сервисам можно обратиться по интернету. Если запрос сначала проходит шлюз, то они должны быть виртуализированы и уже доступны.

Нет никакой журнализации или представления трафика сообщений в течение всего потока.

См.
Этот пример показывает насколько мощной может стать комбинация BPEL и OWSM.
OWSM усиливает BPEL за счет:

Контроля Доступа (Access Control)

BPEL- процесс может быть защищен, если перед ним поставить шлюз. Только аутентифицированние/авторизированные (authenticated/authorized) пользователи могут начать поток [получения] ссуды. Например, если перед BPEL-процессом находится COREid-шлюз политики аутентификации/авторизации (authentication/authorization), то он позволит проход только привилегированным пользователям. Контроль доступа может также быть применен для отдельных сервисов BPEL-процесса.

Частичного/полного шифрования сервисных запросов (Partial/full encryption of service calls)

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

Клиент имеет возможность послать зашифрованное сообщение, которое должно быть расшифровано в некоторый момент в BPEL-процессе. Если вернуться к демо-примеру Loan, клиент может послать зашифрованное сообщение BPEL-процессу. Web-сервис Loan Flow BPEL-процесса получает зашифрованный запрос. На следующем шаге нужно вызвать сервис, который даст кредитную оценку. Поэтому желательно поместить шлюз, который может расшифровать сообщение, перед этим - Credit Rating Service - сервисом.

DMZ-виртуализации асинхронных BPEL-сервисов (DMZ Virtualization of asynchronous BPEL services)

Архитекторы служб безопасности и web-сервисов часто хотят виртуализировать возврат (callback) к BPEL-процессам. Это означает то, что клиент не должен непосредственно общаться с BPEL-процессом. Вместо этого, возвраты должны проходить через некий модуль доступа (proxy) и только затем быть соответственно маршрутизированы (route). Для подобных запросов OWSM может установить режим шлюза (Gateway mode) и proxy-модуль. Одновременно OWSM также может выполнять и другие интеллектуальные задачи обработки, как-то: проверка достоверности сообщений (message validation), регистрация (logging) и применение дополнительных политик безопасности (extra security policies).

Мониторинга (Monitoring)

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

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

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

Работа с двумя и более документами

Автотекст и автозамена

Автотекст

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

названия и адреса компании;

логотипа компании;

стандартных абзацев (например, разделов контрактов);

таблиц.

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

Создание элемента автотекста
1. Выделите текст или рисунок, который следует сохранить в виде элемента списка автотекста.
2. Выберите команду Автотекст в меню Вставка (Insert, AutoText), а затем - команду Создать (Create) (рис. 75).

Автозамена

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

Добавление элемента в список автозамены

Добавление элемента в список автозамены

1. Выберите команду Автозамена в меню Сервис (Tools, AutoCorrect) (рис. 78).
2. Установите флажок Заменять при вводе (Replace text as you type).
3. В поле Заменить (Replace) введите слово или словосочетание, в котором часто встречается опечатка, например введите дял.
4. В поле На (With) введите правильное написание этого слова, например введите для.
5. Нажмите кнопку Добавить (Replace).

Документооборот: два в одном

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

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

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

СЭД как часть архитектуры системы комплексной автоматизации предприятия. Здесь функции СЭД "зашиты" в саму систему управления. Совместное использование технологий комплексной автоматизации управления и документооборота сочетает в себе их достоинства и недостатки. Рассмотрим подробнее третий вариант СЭД.

На практике

Рассмотрим систему, реально работающую на предприятии оптовой торговли, имеющем также собственное производство. Реализация схем бизнес-процессов, интерпретируемых аналогично рис. 1 и 2, позволяет использовать не две разрозненные системы, а одну. Рассматриваемое решение основано на системе Avacco компании Avacco Soft.
Архитектура системы Система Avacco имеет трехзвенную клиент-серверную архитектуру. Первый уровень — сервер баз данных Microsoft SQL Server, в котором содержится вся информация компании, состоящая из двух частей. В одной базе данных хранится информация, вводимая пользователем и необходимая ему для работы (документы, константы, контрагенты, финансовые операции, товарные операции, курсы валют и проч.), а в другой — системная информация, в том числе, имена пользователей, их пароли и права, настройки системы (разным пользователям может быть показан разный набор папок и меню).
Второй уровень — сервер бизнес-логики, выполняющий прикладные алгоритмы по изменению данных, реализующий технологии документооборота, автоматизации бизнес-процессов, потоков работ, разного рода аналитику, агрегирование данных и поддерживающий функции защиты информации и алгоритмов. В функцию сервера бизнес-логики входит также связь сервера баз данных с клиентским приложением. Именно сервер бизнес-логики реализует схемы рис. 1 и 2.
Третий уровень — клиентские приложения VBA Client и Internet Client, позволяющие пользователю «общаться» с сервером бизнес-логики, предоставляющие всю информацию в удобном виде, в частности, визуализируя документооборот. Для VBA Client требуется наличие корпоративной сети, а Internet Client позволяет работать с данными через Сеть.
Финансовый и товарный учет Отличительной особенностью интегрированного документооборота является участие в нем финансовых, товарных и прочих документов, на базе которых осуществляется фактический учет, отображающийся на счетах компании. Речь идет не о приказах и корреспонденции, а о реальных накладных, по которым в этот момент отгружается товар, и о реальных финансовых операциях.
Применительно к системе документооборота это означает, что все изменения в документах не нужно дублировать: они тут же отображаются в единой (для документооборота и системы автоматизации) базе данных, с ними можно оперативно работать, известно, что данные находятся в актуальном состоянии. Поскольку система включает в себя и средства электронной коммерции, то в документооборот вовлечены также документы, формируемые при работе электронного магазина.

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

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


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

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

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


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

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

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


Для этих целей используется язык Visual Basic for Application.

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

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

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

Открытие нескольких документов...

Открытие нескольких документов Работа сразу с несколькими открытыми документами позволяет пользователю:

перемещаться между документами и работать с ними;

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

копировать и перемещать текст, графику и объекты между открытыми документами;

располагать рядом окна документов для упрощения процедуры перетаскивания и копирования.

1. Выберите Файл, Открыть (File, Open). Появится панель диалога Открыть (Open).
2. Найдите файлы, которые нужно открыть.
3. Выберите первый открываемый файл и, удерживая Ctrl, щелкните мышью на каждом из оставшихся для открытия файлов.
Для открытия последовательной группы файлов выберите первый файл и, удерживая Shift, щелкните на последнем файле, который должен быть открыт.

Последовательность действий, пользователя

Последовательность действий, пользователя

1. Внесение поправок к отчету.
2. Создание нового документа для составления письма. Письмо сохраняется, распечатывается и остается для внесения поправок и согласования.
3. Продолжение внесения поправок к отчету. Выделенные в других документах фрагменты копируются в отчетный документ.
4. Внесение поправок в письмо (оно сохраняется, распечатывается и закрывается).
5. Копирование из второго документа заканчивается, и он закрывается.
6. Завершение отчета.
Работа ведется с несколькими документами одновременно. Список открытых документов можно посмотреть в меню Окно (Window).

Работа с двумя и более документами

Работа с двумя и более документами

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

отчет, который необходимо исправить сегодня;

документ, содержимое которого нужно скопировать в отчет, также открыт;

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

Создание элемента автотекста

Рис. 75. Создание элемента автотекста


3. Примите имя элемента списка автотекста, предложенное по умолчанию, или в ведите другое имя.
4. Нажмите ОК.
Имеются встроенные элементы списка автотекста (обращения, прощания и т. п.), которые можно использовать при написании гшсем (рис. 76).

Встроенные элементы автотекста

Рис. 76. Встроенные элементы автотекста


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

Вставка элемента автотекста

Рис. 77. Вставка элемента автотекста


Для вставки элемента из полного списка автотекста можно использовать такую последовательность действий:
1. Выберите команду Автотекст в меню Вставка (Insert, AutoText), затем строку -Автотекст из подменю.
2. Установите флажок Автозавершение для автотекста и дат.
3. Выберите нужный элемент из списка элементов автотекста.
4. Нажмите кнопку Вставить, затем ОК.
В дальнейшем при введении в документ нескольких первых символов имени элемента автотекста нажмите клавишу F3, чтобы принять предложенный элемент списка автотекста. В противном случае продолжите ввод.

Автозамена

Рис. 78. Автозамена


Автозамена часто используется для расшифровки аббревиатур, например МГУ - Московский государственный университет.
Для настройки параметров автозамены выберите команду Автозамена в меню Сервис (Tools, AutoCorrect). При работе с текстом все переключатели должны быть включены. Табл. 15 описывает параметры команды Автоэамена.

Параметры автоэамены

Таблица 15. Параметры автоэамены

Параметры автозамены	Операция
Исправлять две прописные буквы в начале слова	Замена второй прописной буквы строчной
Делать первые буквы предложений прописными	Замена первой строчной буквы в начале предложения прописной
Устранять последствия случайного нажатия CAPS LOCK	Изменение размеров неверно введенных букв и выключение режима CAPS LOCK

Если в диалоговом окне Автоэамена установлен флажок Заменять при моде (Replace text as you type), то при автозамене будут автоматически исправляться ошибки и вставляться требуемые объекты (текст, графика и символы).
В стандартный список автозамены включено большинство чаще всего используемых символов. Например, введите (с) для автоматической вставки символа ©. Существует возможность дополнить список символов-элементов автозамены. Для этого выберите команду Символ в меню Вставка (Insert, Symbol), выделите нужный символ, нажмите кнопку Автоэамена, а затем сохраните элемент списка автозамены как обычно.
Не рекомендуется присваивать элементу списка автозамены реальных имен (например, для расшифровки сокращений). Используйте такие имена, которые не встречаются в реальной работе.

Удаление элемента списка автотекста

Удаление элемента списка автотекста

1. Выберите команду Автотекст в меню Вставка (Insert, AutoText), а затем строку Автотекст из подменю.
2. В поле Имя элемента выберите имя элемента списка автотекста, который следует удалить.
3. Нажмите кнопку Удалить (Delete).
Отменить удаление элемента списка автотекста нельзя.

название фирмы на английском языке

Создание и вставка элемента автотекста
1. Введите и выделите текст (например, название фирмы на английском языке - Training Center KUDITS), который следует сохранить в виде элемента списка автотекста.
2. Выберите команду Автотекст в меню Вставка, а затем команду Создать.
3. Введите имя элемента списка автотекста, например цо.
4. Нажмите ОК.
5. Выберите команду Автотекст в меню Вставка, затем строку Автотекст из подменю.
6. Установите флажок Автоэавершение для автотекста и дат.
7. Установите курсор в место ввода автотекста.
8. Введите в документ символы имени цо и нажмите клавишу F3.

В теории

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

Рис. 1. Бизнес-процесс «Возврат товара покупателю»

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

Рис. 2. Взаимодействие некоторых составляющих работы предприятия

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

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

Вставка элемента списка автотекста

Вставка элемента списка автотекста

При вставке элемента автотекста в документ пользователю предлагается выбор из списка элементов, соответствующих используемому шаблону, а также из шаблона Обычный.
1. Установите курсор в то место текста, куда следует вставить элемент списка автотекста.
2. Выберите команду Автотекст в меню Вставка (Insert, AutoText). Чтобы увидеть полный список встроенных элементов автотекста, при выборе команды Автотекст удерживайте нажатой клавишу Shift (рис. 77).
3. Выберите имя нужного элемента списка автотекста.
4. Нажмите кнопку Вставить (Insert).

Нельзя однозначно сказать, что система

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

Закрытие всех открытых документов

В Word и Excel можно закрыть несколько документов одновременно. Удерживая Shift, выберите команду Закрыть все в меню Файл (File, Close All).
Все открытые документы закроются. Если изменения в одном из документов не были предварительно сохранены, пользователю будет предложено сделать это перед закрытием документа.



    Учет: Делопроизводство - Автоматизация - Софт

• Управленческий учет
  
• Технологии управленческого учета
  
  
• Делопроизводство
  
• Стандарты делопроизводства
  
• Делопроизводство предприятия
  
• Секретарь и делопроизводство
  
• Автоматизация делопроизводства
  
  
• Документооборот
  
  
• Автоматизация
  
• Автоматизация управления
  
• Практика автоматизации
  
• Софт для автоматизации
  

---

---