Платину добывают так же, как и золото – промывают песок, собирают драгоценные крупинки, а затем переплавляют. Регулярные работы по добыче платины на месторождении Кондер в Хабаровском крае были начаты старателями Амурской артели еще в 1984 году.
Как оказалось, залежи платины здесь огромны, о чем свидетельствуют самородки весом от полутора до трех и полтора килограмма.
В 2007 году был образован холдинг «Русская Платина», в который вошли артель «Амур» и ряд других предприятий.
А когда возникает холдинг, неизбежно возникает необходимость в автоматизации документооборота, поскольку бизнес-процессы усложняются, их участников разделяют тысячи километров, причем не только с бумагой, даже с электронной почтой и таблицами Excel для регистрации документов.
, становится невозможным обработать весь поток.
В общем, группа компаний «Русская Платина» решила внедрить СЭД ТЕЗИС .
Документооборот в холдинге – конкретные княжества или вертикаль власти
Любой холдинг имеет распределённую структуру, это аксиома.Поэтому любая система, претендующая на звание корпоративной, должна иметь возможность работать в распределенном режиме.
Но нужно учитывать нюансы — распределенный режим может быть реализован по-разному.
Если взять СЭД в каком-нибудь холдинге, то чаще всего оказывается, что на самом деле действуют несколько отдельных одинаковых или очень похожих систем - в головном офисе и в дочерних компаниях, которые обмениваются между собой входящими и исходящими документами.
Хорошо это или плохо сказать невозможно – если заказчику так удобно, то почему бы и нет? Наше решение было построено аналогичным образом в НК «Альянс» .
Там было установлено несколько серверов, но использовались локальные каталоги, которые везде были разные, а компании холдинга общались друг с другом посредством входящих и исходящих звонков.
Однако в учетной системе существовал справочник глобальных контрагентов, который синхронизировался с СЭД.
Чтобы обеспечить пользователям прозрачность работы в распределенной среде, мы сделали «фантомные карты» (так их называли между собой).
Это когда карточка создается в основной системе, она отображается во всех списках и результатах поиска, а при нажатии на нее вы попадаете в дочернюю систему.
Таким образом, нам удалось избежать дублирования документов и последующих коллизий при их редактировании в разных системах.
Можно пойти другим путем, когда выстроена единая система управления со сквозными бизнес-процессами и документы перемещаются с сервера на сервер по мере необходимости.
Решение о том, какую конфигурацию выбрать, полностью остается на стороне заказчика; это зависит от принятой модели управления холдингом и от степени автономности дочерних компаний.
Хоть мы и считаем, что с точки зрения ИТ лучше иметь единую базу данных и общие каталоги, это не всегда возможно – по техническим или административным причинам.
Распределенная, но единая система
В «Русской Платине» все устроено совершенно иначе, не так, как в НК «Альянс».Сразу было понятно, что нам придется строить распределенную систему со сквозными процессами и устанавливать два сервера.
В отличие от предыдущего проекта здесь появились единые каталоги, которые редактируются только в одном месте, в центре.
Поскольку основная экономическая деятельность осуществляется в Хабаровске, естественно, что там появляется все больше новых подрядчиков.
А каталог хранится на центральном сервере в Москве.
Что я должен делать? Чтобы разрешить этот конфликт, одному пользователю в Хабаровске был предоставлен удаленный VPN-доступ к московскому серверу, чтобы он мог редактировать каталог.
При создании нового контрагента в центральной базе данных запускается процедура репликации и данные копируются на хабаровский сервер.
На первый взгляд это выглядит слишком сложно — почему бы не ввести локальных контрагентов на локальный сервер, а затем позволить двум серверам заниматься друг другом.
Но тогда нам пришлось бы настраивать двунаправленную взаимную репликацию, потому что в Москве тоже могут создавать новых контрагентов, а это на самом деле сложнее, чем иметь один источник данных и просто копировать каталоги на другие серверы.
Секретное оружие — XDBStream
Поэтому мы пошли по пути однонаправленной репликации каталогов центрального сервера по регионам (кроме Хабаровска есть еще Норильск) с помощью нашего XDBStream — сервиса, позволяющего осуществлять репликацию баз данных.Репликация происходит при изменении таблиц в базе данных (добавлении/удалении/редактировании записи).
Для настройки репликации необходимо указать «учетные данные» для доступа к базам данных и указать, какие поля в каких таблицах необходимо синхронизировать.
XDBStream — это не просто какая-то внутренняя разработка, это зарегистрированная программа для ЭVM(!), то есть вполне готовое решение, которое мы используем в проектах, хотя отдельно его не продвигаем.
Хабаровск – Москва и обратно.
Сами карточки документов мы тиражировали через веб-сервисы.
Логика здесь такая: допустим, подрядчик в Хабаровске решает заключить договор с неким ООО «Медведь» на приобретение самосвала для карьера.
Он создает контракт и сначала вызывает внутреннее одобрение.
Проходит ряд раундов, и в конце генеральный директор филиала утверждает договор.
После этого, если соглашение превышает определенную сумму, условно говоря 100 тысяч, его нужно согласовать с Москвой.
Что происходит в этот момент в системе: контракт на локальном сервере переходит в «техническое состояние», то есть блокируется на любые изменения.
Тем временем веб-сервис, который висит на центральном сервере, периодически опрашивает систему — есть ли у меня новые карты? Как только появляется такая карточка, он перетаскивает ее вместе с файлом контента к себе.
Таким образом, соглашение отправляется в Москву.
Далее Москва запускает собственный процесс утверждения.
Затем в Москве он проходит цикл утверждения.
Есть еще один веб-сервис, который показывает Хабаровску, что происходит с их договором там, в Москве - у кого он на данный момент есть, какие визы выданы и т.д. А когда кто-то решает отправить договор обратно в Хабаровск на доработку, он зависает в Москве.
(переходит в техническое состояние) и оживает в Хабаровске, проходя новый этап согласований.
Такая ситуация может повторяться несколько раз, и при этом данные из одной системы всегда видны в другой – там, где в данный момент находится контракт. Если посмотреть с технической стороны, то на самом деле есть две независимые системы Thesis, которые объединяет репликация справочников и вот этот механизм передачи договоров в процессе согласования.
Этот механизм мы разработали на базе XDBStream специально для Русской Платины.
Еще одним преимуществом этого решения является то, что базы документов на двух серверах абсолютно идентичны.
Учет часовых поясов
Разница во времени между Москвой и Хабаровском составляет 7 часов, а расстояние – 6 тысяч километров.Ведение бизнеса в обычном режиме, перевод бизнес-процесса на следующий этап посредством личных разговоров и телефонных звонков, при таких параметрах становится практически невозможным.
Но автоматизированная система должна учитывать и такие детали, что хабаровчане видят все по-своему, а москвичи – по-своему.
Причем все сроки в системе пересчитываются в рабочие дни в родном для участника бизнес-процесса часовом поясе.
Например, в Хабаровске отправили документ на согласование сотруднику в Москву - а там было 2 часа ночи.
Но его рабочий день начинается в 9 часов утра, и даже если процесс утверждения этого документа займет три часа, работник получит его, придя на работу, и срок составит 12 часов по московскому времени.
Логично, что к 5 часам утра никто не согласится на соглашение.
Хорошо, что наша столица находится на западе страны, а не наоборот! Если бы столица была в Хабаровске и все головные офисы располагались там, то все крупные холдинги потеряли бы лишний день на согласование.
Вам нужно внимательно обновлять
Все в мире подвержено изменениям, и программное обеспечение в частности.Либо заказчик просит что-то добавить, то баг исправляют, либо нужно обновить какие-то библиотеки.
Когда системы так тесно связаны друг с другом, одно неловкое движение может привести к неприятным последствиям.
Не обязательно фатально — просто что-то пойдет не так и перестанет работать.
Поэтому при работе системы в распределенной конфигурации необходимо позаботиться о четких процедурах выполнения обновлений.
В нашем проекте конфигурации обоих серверов ТЕСИС — в Москве и Хабаровске — были идентичны, как и сами базы документов.
Чтобы сохранить эту идентичность, обновления развертываются одновременно.
Не совсем синхронно, но в один и тот же день.
Сначала нужно остановить все репликации, потом останавливают хабаровский сервер, обновляют его, потом останавливают и обновляют московский сервер.
Как только это будет сделано, вы сможете снова запустить службы репликации.
Единственный способ добраться до этого таежного края — самолетом.
С точки зрения обычной городской логики менеджеров и консультантов, S&D и другие ИТ-системы необходимо доводить до самого конечного исполнителя – чтобы эффективно автоматизировать бизнес-процессы.
Иначе, мол, возникнет разрыв – кто-то будет бегать с бумажными документами или носить файлы на флешках.
Мы также решили установить рабочие места непосредственно на месторождении Кондер, несмотря на труднодоступность этого участка и проблемы со связью.
Интернет доступен только тогда, когда пролетает спутник.
А в бытовку периодически заходят медведи, так что у людей там другие проблемы, кроме контроля за исполнительской дисциплиной :-) Но тем не менее, наш СЭД ТЕЗИС и это сработало в тайге! Сначала через терминал - люди подключались к компьютеру в Хабаровске и работали, потом, после расширения канала, стали подключаться напрямую к хабаровскому серверу.
Мы меняем процессы, не меняя системы
ТЕЗИС используется в «Русской Платине» с 2012 года, и за это время заказчик не требовал каких-либо серьезных изменений – иногда просили лишь добавить новое поле в карточку или изменить процесс.Тут надо сказать об одной хитрости - у THESIS есть универсальный блок параллельно-последовательного согласования.
Вы можете просто поместить его в дизайнер процессов и настроить так, чтобы оно имело столько стадий и столько параллельных и последовательных блоков, сколько захотите.
А если вдруг изменился какой-то внутренний регламент или, например, уволили пять человек и путь согласования стал быстрее, все, что вам нужно сделать, — это изменить настройки в дизайнере процессов.
Благодаря такой универсальности и гибкости платформы TEZIS удалось просуществовать три года без серьезных модификаций, хотя у заказчика происходили организационные изменения.
ИТ и оптимизация процессов
В идеальной картине мира внедрение системы управления документами и бизнес-процессами должно сопровождаться их существенной оптимизацией – избавлением от бумаги, сокращением согласований и т. д. В жизни это происходит не всегда; организационные изменения требуют воли руководства и давления со стороны конкурентов или регулирующих органов.Ни одна ИТ-система сама по себе не может волшебным образом оптимизировать бизнес-процесс.
IT-специалисты могут только рекомендовать что-то менеджерам, но обычно не имеют возможности настоять, поэтому всегда так сложно оценить эффективность внедрения SЭD и других подобных систем.
С другой стороны, наличие СЭД повышает корпоративную культуру работы с документами и задачами, иногда четко выделяет узкие места и в конечном итоге создает предпосылки для продуктивной работы консультантов по управлению.
Интеграция с 1С – обязательный навык для документооборота
В России вы не сможете внедрить СЭД и ни разу не столкнетесь с требованием интеграции с 1С.Эту компетенцию – умение работать с 1С, пожалуй, следует считать одной из базовых при выборе и оценке поставщика ПО.
Мы не раз интегрировались с 1С, включая достаточно сложные проекты, включая задачи бюджетирования и управления логистикой.
У заказчика было несколько разбросанных баз 1С: Хабаровск, Москва и Норильск.
Одновременно с внедрением ТЕЗИС проводился проект консолидации 1С, в результате которого все базы данных были объединены в одну и очищены справочники.
Однако сделали это не сразу, а в несколько итераций, из-за чего нам приходилось несколько раз перезагружать данные из 1С в нашу систему, в наши каталоги – а это довольно длительная процедура, несколько часов.
Задача была сделать так, чтобы контракты в Москве не были видны из хабаровской 1С, а все видели из центра.
Сначала у нас была интеграция «все со всеми», локальные серверы могли общаться друг с другом, а потом мы перешли к централизованной.
Договор в 1С по сути тоже справочник, таблица - с точки зрения СЭД.
Есть таблица контрагентов, и есть таблица подчиненных ей договоров.
Мы создаем договоры и контрагентов в своем СЭД и затем переносим их в 1С как основные данные.
В результате мы пришли к взаимодействию с 1С в режиме «точка-точка»: центральная база 1С в Москве обменивается данными с сервером ТЕЗИС.
Причем каждая из систем отдельно реплицирует каталоги и документы на региональных серверах.
Для нас это стандартный подход, когда S&D выступает источником основных данных о контрагентах и договорах для учетных систем.
Каналы связи улучшились – ИТ-системы можно централизовать
Прогресс не стоит на месте – связь становится быстрее, надежнее и дешевле.Это дает техническую возможность перейти от распределенной системы к централизованной, дальше дело за руководством.
Год назад «Русская Платина» решила отказаться от хабаровской базы ТЕСИС и перенести все на центральный сервер, но пока отказались только от Черногорки (Норильск).
На самом деле это оказалось несложно, поскольку данные в базах данных идентичны.
В какой-то момент мы просто отключили норильский сервер и перенаправили всех пользователей в Москву.
И все их аккаунты, все документы уже есть, просто на рабочем столе поменялась веб-ссылка на SЭD-сервер, вся рабочая среда осталась прежней.
Несомненно, очередь дойдет и до Хабаровска, потому что в целом централизованную систему легче поддерживать, чем распределенную.
Если взять некий гипотетический холдинг, где есть центральный узел и десять региональных, и к каждому региональному узлу можно добавить еще десять организаций, то во всем холдинге получится сто организаций.
Посмотришь потом - канал Москва-Екатеринбург улучшился.
Вы просто «выбиваете» локальный сервер, и все начинают работать через центр.
То есть мы можем начать внедрение на распределенной конфигурации, а затем перейти к централизованной, без каких-либо переделок и модификаций системы.
Пополняем нашу базу знаний
Каждый проект приносит с собой что-то новое — новые функции, новые решения, интеграции и т. д. Часто бывает, что некоторые модули из проекта затем включаются в основную ветку продукта, способствуя его развитию.Или их просто повторно используют в других проектах, сокращая цикл разработки и внедрения.
Если говорить о «Русской платине», то в базовую поставку THESIS ничего из этого проекта не вошло.
Однако некоторые наработки удалось повторно использовать на другом проекте по автоматизации самарского филиала «РН-Сервис».
У них было два подразделения в Самаре и несколько подразделений в стокилометровой зоне и одна и та же задача - необходимость согласования документов с центральным аппаратом.
Что они делали до введения системы: собрали подписи на документе, сели в машину и поехали в Самару.
Там они сдали бумаги адвокату, затем сходили в Ашан, запаслись продуктами, осмотрели город, забрали свои бумаги и вернулись.
Итого 200 км путешествия и целый день работы на пару подписей.
Хотя Самарская область отнюдь не является каким-то медвежьим уголком, связь в радиусе ста километров от города все же далеко не так хороша.
Поэтому в «РН-Сервис» мы использовали ту же схему координации с локальными серверами, что и в «Русской Платине» — и частые поездки в город отпали.
Уроки выучены
- Мы научились легко трансформировать децентрализованную структуру в централизованную.
- Единые каталоги и управление справочными данными однозначно необходимы.
- Интеграция с 1С обязательна.
(Позже мы даже сделали общий модуль.
)
- Оптимизация процессов — прибыльный бизнес.
Сначала дайте людям работать так, как они привыкли.
-
Возможности Httpurlconnection Из Java.net
19 Oct, 24 -
Вышла Ubuntu 8.04.
19 Oct, 24 -
Новости Openstreetmap №7
19 Oct, 24
