Основные деловые процессы

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

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

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

· собственно оказание услуги;

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

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

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

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

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

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

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

Основы технологии баз и хранилищ данных в логистике

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

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

Хранилища данных

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

· Предметная ориентированность. Информация в хранилище данных организована в соответствии с основными аспектами деятельности предприятия (заказчики, продажи, склад и т.п.); это отличает хранилище данных от оперативной БД, где данные организованы в соответствии с процессами (выписка счетов, отгрузка товара и т.п.). Предметная организация данных в хранилище способствует как значительному упрощению анализа, так и повышению скорости выполнения аналитических запросов. Выражается она, в частности, в использовании иных, чем в оперативных системах, схемах организации данных. В случае хранения данных в реляционной СУБД применяется схема "звезды" (star) или "снежинки" (snowflake). Кроме того, данные могут храниться в специальной многомерной СУБД в n-мерных кубах.

· Интегрированность. Исходные данные извлекаются из оперативных БД, проверяются, очищаются, приводятся к единому виду, в нужной степени агрегируются (то есть вычисляются суммарные показатели) и загружаются в хранилище. Такие интегрированные данные намного проще анализировать.

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

· Неизменяемость. Попав в определенный "исторический слой" хранилища, данные уже никогда не будут изменены. Это также отличает хранилище от оперативной БД, в которой данные все время меняются, "дышат", и один и тот же запрос, выполненный дважды с интервалом в 10 минут, может дать разные результаты. Стабильность данных также облегчает их анализ.