Ит инфраструктура Flashcards | Quizlet

.2 Брокер
(посредник)
объектных
запросовORB(ObjectRequestBroker)

Обобщенная
Архитектура
построения
Брокеров
Объектных
Запросов
разработана
для поддержки
интеграции
самых
разнообразных
объектных
систем.
Спецификация
CORBA устанавливает
принципы
создания
Брокеров
Объектных
Запросов,
которые и
допускают
такую
интеграцию.

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

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

При
определении
конкретной
архитектуры Брокер
Объектных
Запросов
вовсе
необязательно
должен быть
реализован
как один компонент,
но каждая
реализация
должна
реализовывать
три
категории
операций:

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

Ядро
Брокера
Объектных
Запросов
обеспечивает
основные
механизмы
для
манипуляций
объектами и
выполнения
запросов.
Спецификация
CORBA предназначается
для
поддержки
различных
механизмов
реализации
объектов,
поэтому структура
ядра не
определяется.

Объекты

Система
объектов
обеспечивает
клиента набором
сервисов.
Клиент
способен
запросить
некоторый
сервис.
Объект – это
нечто, что обеспечивает
один или
более сервисов,
которые
клиент может
запросить.

Пример
Брокеров
Объектных
Запросов

Доступно
широкое
множество
способов реализации
конкретных
ORB-ов. Далее
будут приведены
примеры
таких
реализаций.
Следует иметь
ввиду, что
конкретный ORB
может быть
реализован
сразу
несколькими
способами.

ORB,
включаемый в
клиентское и
серверное
приложение

Если
имеется
подходящий
механизм
коммуникаций,
то возможна
реализация
ORB-а в виде набора
подпрограмм
как со
стороны
клиента, так
и со стороны
реализации
объекта.
Вызовы методов
могут
транслироваться
в работу со
средствами
взаимодействия
процессов (Inter Process
Communication – IPC).

ORB,
выполненный
в виде
сервера

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

ORB как
часть
системы

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

ORB,
основанный
на
библиотеках

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

Реализации
объектов

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

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

Адаптеры
объектов

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

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

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

Скелет
реализации

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

Динамическая
обработка
запросов

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

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

Запросы

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

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

Под
значением
понимается
допустимый
параметр запроса.
Значение
которое
определяет
объект,
называется
ссылкой на
объект,
связанной с
конкретным
экземпляром
объекта. Выполнение
запроса
вызывает
выполнение
соответствующего
сервиса.
После
завершения запроса
клиенту возвращается
результат
запроса (если
он есть).

Параметр
характеризуется
режимом
передачи и
своим типом.
Режим
определяет,
должно ли
передаваться
значение
параметра от
клиента к
серверу (in), от
сервера к клиенту
(out) или в обоих
направлениях
(inout).

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

Интерфейсы

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

Типу
интерфейса
удовлетворяют
только объектные
типы.

Интерфейс
ORB-а

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

7Система
“БЭСТ-ОФИС”

Система
БЭСТ-ОФИС
обеспечивает
ведение оперативного
и
бухгалтерского
учета на предприятиях
малого
бизнеса и
предназначена
для
руководителей
предприятий,
менеджеров,
работников
склада и
бухгалтерии.
Она позволяет:

–
полностью контролировать
финансовые
потоки;

–
управлять
товарными
запасами
предприятия;

–
регулировать
отношения с
бизнес –
партнерами;

–
формировать
необходимую
бухгалтерскую
и налоговую
отчетность.

В системе
БЭСТ-ОФИС
реализованы
следующие
функции:

– учет финансов;

– учет
взаиморасчетов;

– управление
закупками;

– управление
запасами;

– управление
продажами;

– налоговый
учет;

–
бухгалтерский
учет

– учет
заработной
платы

– учет
имущества

– учет кадров

Система
БЭСТ – ОФИС
предназначена
не только для
бухгалтерской
службы
предприятия,
но и для
использования
оперативными
и
управленческими
работниками.
Это
предполагает
наличие двух
видов учета:

–
Оперативный
учет;

–
Бухгалтерский
учет.

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

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

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

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

Система
БЭСТ – ОФИС
может
работать
только как
система
оперативного
учета и
управленческой
отчетности
(т.е.
подсистема
Бухучет не
используется).
Оперативный
учет можно начать
вести сразу
после
установки
системы,
поскольку
нет
необходимости
в предварительной
настройке
плана счетов
и вводе остатков
по
синтетическим
счетам.

1.
Физический –
определяет
некоторые
физические
характеристики
каналов. На
этом уровне
предъявляются
требования к
характеристикам
кабелей и
разъёмов, к
электрическим
характеристикам
сигналов
(напр., скорость
передачи
сигнала).2.

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

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

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

Транспортный
– отвечает за
стандартизацию
обмена
данными
между программами,
которые
находятся на
различных ЭВМ
сети.5. Сеансовый –
определяет
правила
диалога прикладных
программ,
правила
рестарта,
правила
доступа к
сетевым
ресурсам.

Фактически
контролирует
право на
доступ. 6.
Представительный
– определяет
форматы данных,
алфавиты и
коды
представления
спецсимволов,
псевдографических
символах и
т.д. Уровень
состоит из
многих
синтаксических
таблиц
(телетайп, ASCII,
видеотекс и
т.д.).7.

Прикладной –
занимается
поддержкой
прикладного
процесса
конечного
пользователя.
В отличие от 6
уровня, этот
уровень
имеет дело с
семантикой
данных.
Содержит
сервисные
элементы для
поддержки
прикладных
процессов,
таких, как
управление
трудовыми
ресурсами, обмен
финансовыми
данными,
передача/приём
языка
программирования
и обмен
деловыми данными.

Каждый
уровень
“навешивает”
свою порцию информации
к пакету по
мере
прохождения
(кроме
физического).
Все уровни
можно разделить
на 4 группы:” в локальной
сети (1-2);” межсетевая
связь (3-4);” логическая
связь (5);” уровень
взаимодействия
с
приложением
(6-7).

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

Для
нее имеется развитый
математический
аппарат –
реляционные
исчисления и
реляционная
алгебра, где
для баз
данных
(отношений)
определены
теоретически-множественные
операции
(объединения,
вычитания,
пересечение,
соединение и
др.).
Достоинством
РМД явл.
сравнительная
простота
инструментальных
средств ее
поддержки, а
недостатком –
жесткость
структуры данных
(невозможность
задания
строк таблицы
произвольной
длины) и
зависимость
скорости ее
работы от
размера БД.
Для многих
операций,
определенных
в такой
модели, может
оказаться
необходимым
просмотр
всей БД.

Microsoftbusinesssolutionnavision

Microsoft Business
Solutions–Navision —
комплексное
решение,
предназначенное
для
автоматизации
всех видов
хозяйственной
деятельности
небольших и
средних предприятий
с любой
отраслевой и
бизнес-спецификой.
Эта система
охватывает
все аспекты
деятельности
предприятия,
от финансового
и
бухгалтерского
учета до
средств управления
производством
и
отношениями
с клиентами.

Более 35 000
компаний
самого
разного
профиля и
сфер деятельности
используют
этот продукт.
Решение Microsoft Business
Solutions–Navision уже
около 10 лет
известно на
российском
рынке. Все
это время
велись
работы по его
локализации
с учетом
требований
законодательства
и
бухгалтерской
практики
России, результаты
которых
официально
подтверждены
Минфином РФ.

Управление
финансами

•
Поддержка
различных
моделей
учета – бухгалтерского,
управленческого,
учета по  
международным
стандартам (IAS),
GAAP и др.

•
Неограниченное
количество
аналитических
измерений.

•
Многомерный
анализ
данных.

•
Бюджетирование
и финансовое
планирование.

•
Контроль
исполнения
бюджетов.

•
Прогноз
движения
денежных
средств, анализ
ликвидности,
контроль
платежей.

•
Контроль
дебиторской
и
кредиторской
задолженности.

•
Контроль
кредитного
лимита
контрагентов.

•
Анализ просроченной
задолженности.

•
Широкий
спектр
финансовых и
аналитических
отчетов.

•
Тесная
интеграция с
приложениями
Microsoft Office: Word, Excel, Outlook.

•
Встроенный
генератор
финансовой
отчетности.

•
Мультифирменный
учет,
консолидация.

•
Многовалютный
учет.

•
Полный аудит
операций.

•
Локализация
для
российских
условий.

Бухгалтерский
и налоговый
учет

•
Двойная
запись
проводки.

•
Автоматизация
всех
участков
бухгалтерии.

•
Учет
банковских и
кассовых
операций.

•
Расчеты с
покупателями
и
поставщиками.

•
Учет
Основных
Средств.

•
Учет
складских
операций.

•
Книга
покупок,
Книга продаж,
расчет налогов.

•
Набор
унифицированных
форм
бухгалтерской
и налоговой
отчетности.

•
Налоговый
учет,
формирование
налоговых регистров.

Дистрибуция

•
Контроль
себестоимости
склада.

•
Управление
ценами и
скидками.

•
Управление
товарооборотом.

•
Управление
возвратами.

•
Партионный
учет и учет
по серийным
номерам.

•
Управление
инфраструктурой
склада:

•
перемещение,
подбор,
отгрузка,
приемка, переброска
и т. д.;

•
механизм
оптимизации
складского
пространства;

•
автоматизированная
система
сбора данных
при помощи
радиотерминальных
устройств (ADCS).

•
Межскладские
перемещения,
учет товаров в
пути.

•
Потоварный
учет
себестоимости
(модели FIFO, LIFO,
средняя, по
серийным
номерам,
стандартная).

•
Различные
механизмы
резервирования.

•
Контроль
загрузки
склада на
уровне ячеек.

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

•
Управление
дискретным
производством.

•
Поэтапное
формирование
производственных
заказов.

•
Многоверсионность
спецификаций
и маршрутов.

•
Планирование
поставок,
прогнозирование
спроса.

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

•Перераспределение
производственных
заданий
между
производственными
мощностями.

•
Функции
ограничения
мощностей.

•
Операции
субподряда и
учет
себестоимости
субподряда.

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

•
Функция
интерактивных
указаний,
изменение
политики
производства
“на лету”.

•
Поддержка
разных
политик
производства
(производство
под заказ, на
склад,
смешанное).

Кадровый
учет и
заработная
плата

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

•
Учет
распоряжений
по персоналу:
приказы на
прием,
перевод,
увольнение и
т. д.

•
Расчет
заработной
платы одного
сотрудника
или группы по
различным
алгоритмам.

•
Полная
интеграция с
модулем
“Финансы”.

•
Интеграция с
другими
программами
для передачи
соответствующей
информации
проверяющим
налоговым
органам,
Пенсионному
фонду и др.

Управление
отношениями
с клиентами (CRM)

•
Ведение базы
контрагентов.

•
Списки
рассылки.

•
Сегментирование
контактов.

•
Маркетинговые
кампании.

•
Управление
контактами.

•
Классификация
по отраслям и
прочим критериям,
группировка.

•
Профилирование.

•
Коммерческие
предложения.

•
Календари,
задачи в
разрезе
команды
менеджеров.

•
История
документооборота.

•
Планирование
задач.

•
Протоколирование
взаимодействий.

•
Анализ
продаж.

•
Интеграция с
Word, Outlook
(автоматическая
рассылка
сообщений
электронной
почты).

Сервисный
центр

•
Управление
сервисными
единицами.

•
Ценообразование.

•
Сервисные
заказы.

•
Ведение
контрактов
на сервисное
обслуживание.

•
Планирование
и
диспетчеризация.

•
Планы-графики
сервисных
работ.

•
Контроль
ресурсов,
относящихся
к сервисному
обслуживанию.

Продукты
электронного
бизнеса

Siteline

          Это
КИС класса ERP,
установленная
на многих
промышленных
предприятиях
мира. Она
обладает
полным набором
функций для
автоматизации
всех участков
деятельности
промышленного
предприятия:
материально –
технического
снабжения,
производства,
сбыта,
распределения
готовой
продукции и
финансового
учета.

Стандартная
версия
программного
обеспечения
SyteLine v.2.g00 включает
следующие
модули:

1.
Технико –
экономическое
управление
предприятием.

2.
Материально-техническое
обеспечение
производства
и складской
учет.

3.
Оперативно-календарное
управление
основным
производством.

4.
Бухгалтерия
и Учет.

          Модуль
«Технико
–
экономическое
управление
предприятием»
поддерживает
следующие
функции:

·       
калькуляция
плановой себестоимости
проектируемого
изделия;

·       
калькуляция
плановой
себестоимости
изготовляемого
изделия;

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

·       
оценка
рентабельности
планируемого
или выпускаемого
изделия;

·       
оценка
рентабельности
заказа;

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

·       
стоимости
работы
основного
производственного
персонала (на
основе норм);

·       
стоимости
работы
оборудования
цехов основного
производства
(основанной
на нормах);

·       
стоимости
конструкторских
разработок (основанной
на нормах, на
основе
исторических
данных);

·       
маршруте
изготовления
изделия с
учетом времени
изготовления,
времени на
наладку оборудования;

·       
стоимостных
норм
переменных и
постоянных
накладных
расходов;

·       
стоимости
материалов
(закупаемых и
производимых).

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

·       
получение
информации
об
отклонениях
фактической
себестоимости
от плановой и
анализ этих
отклонений.

Модуль «Материально-техническое
обеспечение
производства
и складской
учет»
поддерживает
такие
функции:

·       
ведение
информации
(код,
наименование,
местоположение
и т.п.) по
складам и
местам складирования
предприятия;

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

·       
отслеживание
движений
всех запасов
материальных
объектов на
предприятии,
включая
обеспечение
действий по:

·       
оприходованию
материалов
от
поставщика, перемещение
материалов
между
складами и
местами
складирования;

·       
инвентаризации
запасов;

·       
отпуску
и получению
материалов в
производство;

·       
планирование
закупок (на
основании
информации,
получаемой
из модуля
“Планирование
потребностей
в материалах
и планирование
производственной
деятельности”);

·       
действия
по закупкам:

·       
формирование
заявок на
закупку, их
рассмотрение;

·       
создание
заказа
поставщику;

·       
отслеживание
заказов;

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

·       
получение
выходной
информации
для анализа
состояния
запасов на
предприятии
и для
совершения необходимых
мероприятий.

Модуль
«Оперативно-календарное
управление
основным
производством»
реализует
функции:

·       
составление
и ввод в
систему
плана выпуска
продукции;

·       
оценка
возможности
выполнения
плана, исходя
из ресурсов
(оборудование,
персонал,
материалы),
существующих
на
предприятии
в определённые
моменты
времени;

·       
расчет
требуемых
для
выполнения
заданного
плана
ресурсов
(оборудование,
персонал, материалы);

·       
оценка
загрузки
производственных
мощностей;

·       
планирование
производственных
заданий;

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

·       
учет
хода
производства:
регистрация
выпущенных
Деталей/Сборочных
узлов/Единиц
и готовой
продукции;

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

·       
составление,
оформление и
проведение
конструкторско-технологических
изменений.

Модуль
«Бухгалтерия
и Учет»
поддерживает
следующие
функции:

Ведение
Бухгалтерии
поставщиков:

·       
 регистрация
счетов-фактур
поставщиков
с
автоматическим
созданием
соответствующих
проводок;

·       
формирование
платежей
поставщикам
(автоматически
или вручную),
регистрация
платежей с
автоматическим
формированием
соответствующих
проводок,
формирование
графика
платежей;

·       
управление
авансовыми
платежами;

·       
отслеживание
сальдо по
поставщикам,
ретроспективного
баланса
(старение
кредиторской
задолженности);

·       
управление
корпоративными
поставщиками.

Ведение
Бухгалтерии
клиентов:

·       
формирование
и
регистрация
счетов-фактур;

·       
регистрация
платежей
клиентов;

·       
управление
авансовыми
платежами;

·       
отслеживание
сальдо
клиентов,
отслеживание
задолженностей
с
возможностью
автоматического
начисления
штрафов;

·       
отслеживание
ретроспективного
баланса (старение
дебиторской
задолженности);

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

·       
управление
корпоративными
клиентами.

Управление
Основными
средствами
(ОС):

·       
ведение
карточки ОС;

·       
автоматический
расчет
амортизации
несколькими
методами;

·       
автоматическое
начисление
амортизации;

·       
проведение
переоценки
ОС;

·       
совершение
действий по
перемещению
и выбытию ОС.

Создание
и ведение
Главной
бухгалтерской
книги:

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

·       
получение
выходной
информации
(отчетные формы)
в
соответствии
с
требованиями
российских
стандартов
бухгалтерского
учета (РСБУ) и
международными
стандартами
бухгалтерского
учета (GAAP) одновременно;

·       
проверка
бухгалтерской
информации:
возможность
просмотра
бухгалтерских
проводок до
мест их
возникновения;

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

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

·       
закрытие
периода
(месяц,
квартал, год);

·       
формирование
определенных
пользователем
проводок с
помощью
шаблонов
(типовые операции)
в модуле
аналитического
учета.

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

Замечание.

Система
SiteLine
интегрируется
с рядом других
систем, в
частности, с
приложением SiteLineAPS (Система
точного
планирования)
комплекса SiteLineSuite,
интерактивный
инструмент
конфигурирования
под
требования
конкретных
заказчиков
SyteSelect ( Многофункциональный
конфигуратор
продукции),
приложение
SyteWeb 
(Программное
обеспечение
электронной
коммерции)

Вопрос 11. зачем нужны консультанты?

Приглашаются грузчики для интересной работы…(Из газеты “Работа”)

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

Я уже отмечал, что проект внедрения КИС в коммерческой организации – это проект постановки управленческих технологий с применением средств автоматизации. Поэтому к участию в таком проекте могут привлекаться консультанты по управлению, финансовые, инвестиционные и IT-консультанты (консультанты по информационным технологиям). 

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

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

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

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

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

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

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

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

Вопрос о привлечении или не привлечении консультантов обычно встаёт по причине высокой стоимости их услуг. Действительно, стоимость 1одного дня работы западного консультанта в сфере внедрения ERP-систем может превышать $1000 (аппетиты российских консалтинговых фирм значительно скромнее).

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

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

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

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

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

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

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

Говорить о “дороговизне” консультантов следовало бы в сравнении с “дешивизной” собственных отделов АСУ. Чаще всего, эта “дешивизна” кажущаяся. Если в компании уже имеется какая-то минимальная автоматизированная система, то с началом внедрения КИС специалисты, занимающиеся сопровождением этой системы, не смогут одновременно выполнять обе задачи.

Причём, не ПОСЛЕ внедрения, а как обычно – ДО. Сроки внедрения собственными силами на практике намного превосходят сроки проектов с участием внешних консультантов. Как следствие – увеличение сроков окупаемости КИС. 

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

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

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

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

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

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

Idl
(interfacedefinitionlanguage – язык определения
интерфейсов)

Язык
описания
интерфейсов
(IDL),
используемый
OMG определяет
типы
объектов
посредством
спецификации
их
интерфейсов.
Интерфейс
состоит из
множества
именованных
операций и их
параметров.

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

Отображение
IDL в языки
программирования

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

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

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

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

Типы данных

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

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

Определены
следующие
основные
(базовые) типы
данных:

1.    
16 и 32
разрядные
знаковые и
беззнаковые
целые типы;

2.    
32 и 64
разрядные
типы с
плавающей
точкой в соответствии
с IEEE;

3.    
Символьный
тип в
соответствии
с ISO Latin-1 (8859.1);

4.    
Логический
тип с
множеством
значений
истина и
ложь;

5.    
8
разрядный
тип, который
гарантированно
не подвергается
никаким
изменениям
при передаче
между
различными
системами;

6.    
Перечислимые
типы,
состоящие из последовательности
идентификаторов;

7.    
Строковый
тип,
состоящий из
последовательности
символов
переменной
длины, длина
строки
доступна во
время
выполнения
программы;

8.    
Тип “any”,
который
может
принимать
значения всех
базовых и
составных
типов.

Также
могут быть
определены
составные
типы:

1.    
структура,
состоящая из
упорядоченных
пар (имя,
значение);

2.    
объединение,
состоящее из
дискриминатора
и значения
типа,
связанного с
дискриминатором;

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

4.    
массив
фиксированной
длины,
элементами которого
являются
значения
одного типа;

5.    
тип
интерфейс,
который
определяет
множество
операций,
которое
должен
поддерживать
экземпляр
этого типа.

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

Синтаксис
Общего
Представления
Данных – CDR

CDR – это способ
представления
всех типов
данных,
определенных
в OMG IDL в виде
последовательности
восьмиразрядных
величин,
далее
называемых
байтами.

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

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

Кодирование
базовых
типов

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

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

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

Таким
образом значение,
имеющее
размер n
должно
кодироваться
с позиции m*n,
где m – это
целое число.
В CDR n может
принимать
значения 1, 2, 4
или 8. Если
необходимо,
то
выровненному
значению
предшествует
область
минимально
возможного
размера,
необходимого
для
выравнивания.
Значение
байтов
внутри этой
области не
определено.

Выравнивание
определяется
относительно
начала
потока.
Первый байт в
сообщении
или инкапсуляции
имеет индекс
0.

Кодирование
составных
типов

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

Элементы
структуры
кодируются в
том порядке,
в котором они
определены в
описании на IDL.
Каждый
элемент
кодируется
образом, соответствующим
его типу.

Объединение
кодируется
значением дискриминатора
и членом
объединения,
соответствующим
данному
значению.

Массив
кодируется
как
последовательность
его
элементов.
Так как длина
массива фиксирована,
она не
кодируется.
Если массив
имеет
несколько
измерений, то
первый
индекс изменяется
наиболее
медленно, а
последний –
наиболее
быстро.

Последовательность
элементов
кодируется
как величина
типа unsigned long, за
которым
следуют элементы
последовательности.
Это значение
определяет
количество
элементов.
Каждый
элемент
кодируется в
соответствии
со своим
типом.

Строка
кодируется
как величина
типа unsigned long, содержащее
длину строки,
и отдельными
символами –
элементами
строки. Длина
строки и ее представление
в виде списка
символов включают
завершающий
нулевой
символ, что
дает
возможность
использования
стандартных
функций
библиотеки
языка C (например,
strcpy) для
декодирования
сообщения.

Значение
перечислимого
типа
кодируется в
виде
величины
типа unsigned long,
соответствующей
данному
значению.
Первому в
порядке
перечисления
в
определении
на IDL значению
соответствует
0, второму – 1 и
так далее.

Кодирование
инкапсуляции

Первый байт
инкапсуляции
кодирует
порядок байт
внутри нее –
значение
типа 0
означает
кодирования
по принципу
первым –
старший байт,
1 – младший.
Далее идут
данные. Флаг
порядка байт
не
включается в
данные, но он
включается в
инкапсуляцию.

Все значения
внутри
инкапсуляции
выравниваются
относительно
ее начала,
первый байт
(с индексом 0)
соответственно
занимает
флаг порядка
байт. Если
инкапсуляция
кодируется
как
последовательность
величин типа
octet (байтов), то
ей
предшествует
значение типа
unsigned long,
содержащее
общий размер
инкапсуляции.

Кодирование
псевдообъектов

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

Операции

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

1.    
спецификации
параметров,
требуемых
для выполнения
операции

2.    
спецификации
возвращаемого
значения

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

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

5.    
индикации
семантики,
которую
клиент должен
учитывать
при
выполнении
операции.

Хранилище
описаний

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

Эта
информация
может быть
использована
для выполнения
запроса –
таким
образом
программа, которая
не
предусматривала
использование
объекта
какого-либо
типа,
определить
доступные у
этого типа
методы, типы
его параметров
и
осуществить
вызов.