Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Digital Directum

Опрос

Вы используете

Библиотека

02.11.2010 13:33
  от автора
  Репин

ARIS eEPC или «Процедура» Business Studio?

Оценки за материал: 5.00 (1)

Во многих современных системах класса Business Process Management (BPMS) для описания «исполняемых» процессов применяется спецификация BPMN (версия 1, 2). Эта спецификация является, вероятно, лучшей для целей формализации автоматизируемых процессов. Однако для описания и регламентации процессов, исполняемых людьми, она является слишком сложной так же, как и некоторые другие нотации, появившиеся ранее.
В статье рассмотрены проблемы выбора нотаций, адекватных задаче описания и регламентации процессов, исполняемых людьми. Выполнено сравнение нотации ARIS eEPC, «простой блок-схемы» в MS Visio и «Процедуры» Business Studio.
Делаются выводы о целесообразности выбора нотации для комплексного описания и регламентации процессов компании.
Введение

Довольно типичной является ситуация, когда директор по развитию ставит задачу своим специалистам выбрать нотации (методики), которые будут в дальнейшем использоваться для описания и регламентации бизнес-процессов компании. При осуществлении такого выбора целесообразно учитывать, как минимум, следующие четыре аспекта:
1.возможности нотации для описания процессов требуемого уровня сложности;
2.возможности среды моделирования, поддерживающей выбранную нотацию;
3.наличие методики применения выбранной нотации и соответствующего инструмента для решения поставленных задач в рамках проекта;
4.наличие специалистов с компетенциями, необходимыми для использования нотации и инструмента с учетом требования методики выполнения проекта.

Если цели проекта сформулированы нечетко, то выбор нотации, скорее всего, будет выполнен ошибочно. Рассмотрим, в качестве примера, следующую формулировку: «Мы хотим описать и автоматизировать наиболее важные бизнес-процессы в BPMS, регламентировать работу всех сотрудников компании и описать требования для доработки существующего программного обеспечения». Такая фраза содержит несколько совершенно разнородных задач:
1. описание исполняемых процессов в рамках системы BPM;
2. регламентация деятельности сотрудников при помощи внутренних нормативно-методических документов (т.е. создание регламентной базы);
3. описание требования к программному обеспечению.

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

Нотация BPMN является наиболее удобной (в ряду существующих в настоящее время) для описания «автоматически исполняемых» процессов. Но она не удобна для создания относительно простых схем в регламентирующих документах для сотрудников по следующим причинам:
1. наличие слишком сложной и избыточной для описания простых процессов семантики;
2. неудобство при создании сложной, многоуровневой процессной модели организации в целом;
3. значительные сложности по обучению сотрудников компании (в силу сложности спецификации и дефицита специалистов, способных проводить такое обучение).

Для создания схем процессов, которые будут «прозрачны» и понятны большинству сотрудников компании без длительного и сложного обучения, необходима другая нотация. Интересно рассмотреть некоторые популярные на сегодняшний день нотации с точки зрения следующих факторов:
1. простота в освоении, интуитивная понятность для сотрудников компании;
2. приемлемая информативность схем процессов при минимальном наборе используемых графических символов;
3. поддержка нотации современными средствами моделирования;
4. затраты на внедрение методики описания и регламентации процессов с использованием соответствующего инструмента.

Нотация ARIS eEPC


Нотация ARIS eEPC была одной из первых нотаций, получившей широкую известность на российском рынке. Она относится к нотации типа Work Flow (поток работ). Особенностями нотации является наличие элементов типа «событие» и наличие операторов логики: «и», «неисключающее или», «исключающее или» (см. рис. 1).


Рис. 1. Схема процесса в нотации ARIS eEPC.

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

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

Возникает вопрос: а за что, собственно, боролись? Типичная схема в ARIS eEPC:
1. не годится для автоматизации в системе класса BPM (нужно применять дополнительный транслятор, переводящий ее в нотацию BPMN, с последующей ручной доработкой);
2. сложна для восприятия рядовыми сотрудниками компании (их нужно учить правилам использования логических операторов и корректному чтению схем, которые их содержат).

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

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

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

«Простая блок-схема»
      

Нотация «простая блок-схема» реализована в популярном офисном продукте MS Visio. На рис. 2. показаны элементы этой нотации и фрагмент соответствующей схемы. В полном объеме рассматриваемая нотация применяется редко.

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

Нотация «простая блок-схема» в своем самом простом и часто используемом на практике варианте, содержит всего несколько элементов:
1. процесс;
2. решение;
3. ручная операции (реже);
4. документ;
5. данные;
6. стрелка (для отображения связей между объектами схемы).

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


Рис. 2. Нотация «Простая блок-схема» в MS Visio.

Рассмотрим некоторые особенности применения «Простой блок-схемы», в частности применение стрелок. На практике, сотрудники компании, формирующие схемы при помощи «Простой блок-схемы» придерживаются двух подходов:
1. не именуют стрелки вообще;
2. стараются присваивать стрелкам, связывающие элементы схемы, простые и понятные названия.

На рис. 3 показан пример применения нотации «Простая блок-схема» в одной из компаний. Использованы все пять типов элементов. Тем не менее, схема выглядит вполне читаемой и понятной пользователю – сотруднику компании.

Нотация «Простая блок-схема» при использовании в компаниях часто подвергается различным вариациям:
1. изменяется смысл элемента «решение»;
2. по-разному используют стрелки связей (именуют или не именуют и т.п.);
3. по-разному используют стрелки связей в сочетании с объектом «документ»;
4. прочее.

Интересно, что нотация «простая блок-схема» в том или ином виде часто используется специалистами по менеджменту качества при описании процессов СМК.
      

Рис. 3. Пример схемы в нотации «Простая блок-схема».

Преимуществами нотации «Простая блок-схема» (с сокращенным до минимума количество элементов) являются:
1. простота формирования графических схем процессов;
2. интуитивная понятность схем сотрудникам (даже без специального обучения);
3. минимальная потребность в обучении сотрудников;
4. наличие доступных инструментов для описания процессов (MS Visio, MS Word).

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

В целом, масштабное использование в компании нотации «Простая блок-схема» без современного средства моделирования представляется весьма неэффективным.

«Процедура» Business Studio


На рис. 4 представлена схема, сформированная в нотации «Процедура» среды моделирования процессов Business Studio (Россия). В рассматриваемой нотации используются следующие условные обозначения:
1. процесс;
2. решение;
3. событие;
4. стрелка предшествования (как в классических нотациях класса Work Flow);
5. стрелка потока объектов;
6. сноска;
7. внешняя ссылка.

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

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

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


Рис. 4. Схема процесса в нотации «Процедура» Business Studio.

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

На рис. 4. видно, что по ходу процесса для повышения информативности схемы используются элементы-события («Ежедневно, в 9-00», «В течение дня», «12-00»). Таким образом, информацию о событиях можно показывать как виде специальных элементов, так и путем соответствующего именования стрелок.

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

В целом, схема процесса в нотации «Процедура» при кажущейся простоте является весьма информативной и удобной для описания. Можно сформулировать следующие преимущества этой нотации (в случае ее использования в Business Studio):
• представлен минимально необходимый набор графических элементов для описания процессов типа Work Flow (поток работ);
• быстрота создания графических схем для целей регламентации;
• возможность повышения информативности схем процессов за счет гибкого использования событий и именованных стрелок (одновременно с возможностью привязки документов к стрелкам и последующей выгрузки информации в регламентирующих документах);
• схемы процессов просты и понятны всем сотрудникам даже без специального обучения;
• простота в обучении (нет необходимости привлекать дорогостоящих специалистов со стороны - обучение можно проводить силами сотрудников отдела орг. развития);
• схемы процессов являются кросс-функциональными, что удобно для описания «сквозных» процессов компании;
• можно выгружать и редактировать схемы в MS Visio (при необходимости).

Среда моделирования Business Studio позволяет достаточно быстро создавать процессную модель компании. Информация о процессах может быть выгружена из системы в виде регламентирующих документов в требуемом формате. Заметим, что в Business Studio есть возможность описывать процессы в нотации ARIS eEPC, нотации IDEF0 и нотации «Процесс» (см. руководство по системе).

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


Таблица 1. Информация о процессе, представленном на рис. 4.


Рис. 5. Пример схемы в нотации «Процедура» в Business Studio.

Выводы

В целом, нотация «Процедура» в версии, реализованной в среде моделирования Business Studio, является более удобной и понятной сотрудникам, чем нотация ARIS eEPC. Она позволяет быстро описывать и регламентировать процессы компании.

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

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

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

В.В. Репин, к.т.н., доцент, Исполнительный директор и партнер ООО «BPM Консалтинг Групп», зав. кафедрой Управления бизнес-процессами НОУ ВПО «ИЭФ «Синергия», основатель портала www.FineXpert.ru

Июль 2010 г.

www.FineXpert.ru – среда общения профессионалов.
www.bpm3.ru – процессы, проекты, эффективность.

Комментарии

Оценки: 1/
23.11.2010 14:25
  от автора
  Елена Дмитриевна
Позволю себе поспорить с автором по части однозначности утверждения: «…нотация «Процедура» в версии, реализованной в среде моделирования Business Studio, является более удобной и понятной сотрудникам, чем нотация ARIS eEPC». Не берусь утверждать, что еЕРС лучше, но несколько ее плюсов могу привести. Если говорить о процессах верхнего уровня, а не об уровне Рабочих инструкций, то eEPC позволяет:
1 Представить на диаграмме движение объекта деятельности в виде отдельного объекта, а не «зашифрованного» в наименование стрелки. Плюс к тому, можно для большой наглядности отразить статус этого объекта. Благодаря этому, при возникновении вопросов у сотрудников уже не будет необходимости «читать» всю диаграмму в поисках информации «где же этот объект получается в таком виде». Достаточно будет лишь пробежать глазами по «статусам» объекта и углубится в изучение подпроцесса.
2 Благодаря «машинной логике» показать четкое и однозначное ветвление процесса. Объект «решение» в нотации «процедура» удобен при альтернативных возможностях дальнейшего хода процесса. Если же имеет место случай «и» или «не исключающее или», то все эти возможности придется отражать в наименовании стрелок или «прятать» в описание процессов, а это, на мой взгляд, снижает читабельность диаграмм.
3 Отразить на диаграмме разницу между «выходом» и «результатом» процесса.
Все эти преимущества будут работать только в том случае, если аналитик грамотно использовал возможности еЕРС. При правильном выборе объектов для отображения (например, для процесса «Перевозка груза» отображать в качестве дополнительного объекта ТМЦ «Груз» со статусами) и при грамотной их компоновке на диаграмме (не в разнобой, а, например: все ТМЦ слева, исполнители справа и т.п.) получится простая и понятная схема процесса, которая полностью иллюстрирует текстовое описание (при соответствующем шаблоне документа). Еще раз повторюсь, что, конечно, описывать в этой методологии документы «нижнего» уровня нецелесообразно.
Оценки: 1/
23.11.2010 19:18
  от автора
  Репин
Спасибо! Некоторые соображения по поводу замечаний к статье.
1. Отображение объектов и их статусов на диаграмме - это хорошо, но при этом количество объектов на схеме вырастает в разы. Как схема с количеством объектов в 3-4 раза большим (чем в "Процедуре") может быть более "наглядной"? Да и что такое "наглядность?". Нам бы с Вами дать четкое операционное определение "наглядности", тогда сравнение будет более адекватным. Кстати, статус документа можно показывать в названии стрелки при помощи квадратных скобок (как в нотации BPMN). Пример: "План продаж [проект]".
2. "Четкое и однозначное" ветвление процесса на практике может быть очень и очень сложным. Сотрудник, профессионально не владеющий нотацией и не имеющий опыта, нарисует такие схемы в eEPC, которые никто потом не поймет. А это означает, что моделирование в ARIS eEPC никогда не будет массовым. Это удел отдельного, специализированного отдела компании. Ресурсы этого подразделения ограничены. Описаний и регламентов они могут за год сделать ограниченное количество. Поэтому, если говорить о внедрении процессного управления в масштабах компании, желательно выбирать более простой и понятный инструмент и нотацию. Кстати, с BPMN тоже ситуация не простая - нужны очень серьезные знания и навыки, чтобы рисовать качественные схемы (см. материалы группы по BPMN ).
3. С моей точки зрения для описания границ процесса надо использовать входы/выходы (преобразуемые и преобразованные ресурсы) и инициирующие/завершающие события (начало/результат). К примеру, формулировка завершающих событий очень близка по смыслу с формулировкой результата процесса (Пример: "План проекта ____ подготовлен и отправлен на согласование в отдел ___").
4. Полностью согласен с Еленой, что качество схемы зависит от квалификации бизнес-аналитика.
Оценки: 1/
24.11.2010 11:52
  от автора
  Елена Дмитриевна
отвечу на Ваши замечания к моим замечаниям.
1. Что вы, о каких таких «разах» речь. Я не говорю о том, чтобы вынести на диаграмму все возможные объекты. На мой взгляд, целесообразно показывать на диаграмме «движение» основного объекта управления. Например, для процесса «производство продукта А» отразить движение этого продукта: Продукт – заготовка, Продукт – обработан, Продукт – охлажден/нагрет… и т.д.
Наглядная схема, в моем понимании, - это схема, на которой отражена логика процесса, исполни-тели каждой функции, на которой можно легко (с первого взгляда) проследить движение основного объекта управления. Конечно же, при этом «значки» схемы должны быть интуитивно понятны или требовать только минимальных пояснений, а также схема не должна быть загромождена лишними элементами. Вообще, понятие наглядности весьма субъективно.
2. Согласна, что в целом, работа в еЕРС требует больше специальных знаний, чем работа в «Проце-дуре». Но при этом, если создание схем процессов передается в подразделения, то все равно требуется обучение (какая бы нотация не была выбрана) и последующая проверка созданных на местах схем. Человек без специальных навыков даже в самом элементарном процессе даже при использовании самой простой методологии способен сделать грандиозные ошибки. Если же на предприятии описанием процессов занимается спец подразделение, то это уже предполагает, что они являются профи в своем деле.
3. По поводу входов/выходов – согласна с Вами и имела в виду тоже самое. Только не всегда «собы-тие» совпадает с результатом. Например «процесс сортировки товара»: завершающим событием будет «товар рассортирован», а вот результатами будет «товар» с разными статусами (на списа-ние, на переоценку и т.п.). Т.е. глядя на схему еЕРС мы увидим какой товар мы имеем на выходе
Оценки: /
24.11.2010 14:33
  от автора
  Дмитрий Пинаев
>>Вообще, понятие наглядности весьма субъективно
Тем не менее, мне кажется, его можно обсудить.
В EPC нужно на диаграмме расопложить три элемента: две стрелки и один объект для обозначения выхода.
В IDEF0 (раз уж речь идет о верхнем уровне) - стрелку с названием.
Т.е. меньше элементов на диаграмме, меньше труда бизнес-аналитику. Чем этот вариант не нагляднее?
Второй момент, на диаграммах верхних уровней результаты бизнес-процессов обычно включают несколько объектов. Например, Конструкторская документация (там и эскиз, и чертеж и пояснительная записка), все это можно прикрепить как объекты к стрелке. Исполнитель увидет их в регламенте как информацию "второго порядка", ненужную на этапе понимания схемы.
Оценки: /
27.11.2010 22:21
  от автора
  Александр Чередниченко
Спасибо автору за статью!
Позволю себе несколько комментариев.
Удобность/ не удобность – штука достаточно субъективная. Однако, при всем моем прохладном отношении ко всяким рейтингам типа Gartner, именно благодаря нотации ЕРС ARIS держится в первой тройке лидеров. И только благодаря, тому, что эта нотация считается наиболее наглядной, ARIS годами на вершине. Как Gartner это определяют? Опрос компаний-клиентов, т.е. по статистике эта нотация считается наиболее наглядной.
По поводу «создания страшных схем ЕРС неопытными пользователями». Думается, нотация тут абсолютно ни при чем, и думается в любом инструменте и при помощи любой нотации можно «нарисовать» страх и ужас
По поводу «Моделирование в ARIS eEPC не дает значительных преимуществ ни для автоматизации, ни для регламентации». Очень субъективно (придерживаюсь противоположного мнения), нотация тут также абсолютно ни при чем, способность использовать результаты моделирования для автоматизации/регламентации определяется ТОЛЬКО корректно выстроенной архитектурой и выбранным подходом к моделированию (и конечно ПО).
По поводу «ее «машинная» логика не удобна для восприятия рядовым сотрудникам компании» - практика показывает обратное
Оценки: 1/1
28.11.2010 17:01
  от автора
  Константин Андреевич
Спасибо автору за возможность общения.
Предлагаю тему «о наилучшей нотации» обсудить в форуме (когда он заработает).[/img]
Любая нотация это инструмент. Инструмент необходим специалистам для решения конкретных задач. Само по себе графическое представление процесса, в какой бы нотации оно ни было исполнено не имеет ценности.
С этой точки зрения интересна диссертация Конева К.А. «Информационно-управляющая система качества менеджмента на основе использования системных моделей…», в которой в частности говорится о назначение моделей, как инструмента по созданию баз данных.
Предназначение моделей, в конечном счете, это создание стандартов организации. Т.е. модель это «скелет» (понятный специалистам), на который в дальнейшем накладывается текст, понятны и доступный большинству.
Оценки: /
09.02.2011 14:29
  от автора
  Елена Дмитриевна
Хотела бы пояснить, что имела в виду, говоря о «процессах верхнего уровня» - это основные процессы компании, из набора этих процессов состоит деятельность компании. Если составлять « карту процессов верхнего уровня компании», то, на мой взгляд, EPC здесь не вариант – здесь действительно гораздо удобнее IDEF. Но вот если уже говорить об описании этих самых процессов – т.е. когда мы рассматриваем уже конкретный процесс, пишем регламент этого процесса, то именно для такого уровня подходит EPC. И именно здесь проявляются все плюсы этой нотации, о которых я говорила ранее.
И, если вернуться к субъективности понятия «наглядность»: лично мне гораздо понятнее схема EPC чем «Процедура», пусть и с большим числом элементов на схеме. А «лично Вам», на сколько я понимаю, гораздо понятнее нотация «Процедура». Поэтому, сколько бы плюсов «за» «процедуру» Вы не приводили, она не станет мне понятнее… поэтому, я все-таки останусь на той точке зрения, что «понятность» субъективна.

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений