4. Гибкость настройки системы: способ настройки системы,
необходимость ввода данных для авторизации.
5. Доступ к статистике. Наличие возможности предоставить
пользователю доступ к собственной статистике и возможность назначения ролей,
разграничивающих доступ.
6. Качество интерфейса.
7. Стоимость системы, которая включает затраты на приобретение,
поддержку и обновление лицензии.
С помощью приведенных выше критериев проанализируем соответствие
системы потребностям организации. Для этого введем шкалу оценки. Оценка
будет производиться по пятибалльной системе, где «1» обозначает полное
несоответствие критерию, а «5» – полное соответствие критерию. Результаты
оценки представлены в таблице 1.6.
Таблица 1.6
Анализ программных продуктов, автоматизирующих учет
рабочего времени
Критерий
Yaware
primeERP
Большой
брат
TimeCamp
Функциональность
3
4
4
3
Принцип работы
3
4
5
4
Информативность
отчетов
4
4
3
4
Гибкость настройки
5
3
3
3
Наличие статистики
4
3
4
4
Интерфейс
4
5
4
3
Стоимость
5
4
5
4
Итого
28
30
28
29
На основании проведенного анализа можно заключить, что перечисленные
системы не удовлетворяют требованиям к функциональности решения и не
обладают необходимой гибкостью настройки. В целом все перечисленные
системы показывают среднюю степень соответствия выделенным критериям. В
связи с этим, при их внедрении будет необходимость доработки функционала
системы под требования организации.
1.3.2 Выбор и обоснование стратегии автоматизации задачи
Целью выбора стратегии автоматизации задачи является снижение затрат и
минимизация бизнес - рисков при решении задач информационной поддержки
основных бизнесов компании [20]. В рамках проекта по созданию стратегии
развития корпоративной информационной системы необходимо реализовать
следующие задачи:
1. Разработка IT-стратегии
2. Формирование стратегического плана (проекты и ресурсы)
3. Описание технической архитектуры IT-системы
Под стратегией автоматизации определяется формализованная система
правил, на основе которых будет создаваться проектируемая ИС.
В процессе создания IT-стратегии учитываются базовые параметры
разрабатываемой ИС, чтобы в дальнейшем она отвечала некоторым требованиям:
• Расширяемость, то есть система должна обеспечивать растущие
потребности компании;
• Настраиваемость, то есть система должна быть проста в управлении
и изменении для внутренних бизнес-процессов и внешней среды;
• Совместимость, то есть все основные компоненты системы должны
быть взаимозаменяемы и соответствовать требованиям ИБ;
• Эффективность работы, то есть применение того или иного решения
должно быть экономически оправдано;
• Независимость, то есть заказчик не сможет попасть в зависимость от
поставщиков решений, при этом у него не возникнет необходимости в содержании
своего штата программистов.
Задача разработки стратегии автоматизации состоит из:
• Подготовительного этапа;
• Изучения, анализа и систематизации главных и вспомогательных
бизнес - процессов фирмы;
• Улучшения принципов управления компании.
Фазы разработки стратегии включают в себя:
• Описание существующих в компании ИС для отражения их
соответствия функциональным задачам бизнеса на всех уровнях управления,
пользовательского окружения, структуры потоков данных, организации их
хранения и доступа к ним;
• Проектирование и исследование главных и вспомогательных
процессов с учетом их информационной поддержки и взаимосвязи с структурой
управления;
• Утверждение целей и задач модернизации информационных
технологий в соответствии с целями и задачами бизнеса. Установка
первоочередных задач автоматизации и подготовка предложений по их
реализации;
• Создание системного проекта по реализации комплексной ИС,
предполагающего объединение действующих и разрабатываемых компонент (по
функциональности, структуре данных, их изменению и организации доступа);
• Технико-экономическое обоснование частей проекта
информатизации компании на базе выделяемых факторов эффективности.
Проект по созданию стратегии реализуется в тесном взаимодействии с
представителями подразделений бизнеса на каждом этапе его разработки. В
проектную команду входят не только IT-специалисты, но и управленческий
состав, руководящий соответствующими бизнес-процессами.
Для автоматизации задачи среди уже созданного множества стратегий
выбирается один из следующих видов автоматизации:
• Хаотичная;
• По участкам;
• По направлениям;
• Полная (комплексная).
К минусам хаотичной автоматизации можно отнести отсутствие полной
стратегии развития автоматизированных систем, что может привести к разработке
незаконченных фрагментов информационной инфраструктуры и прикладных
систем, которые нельзя будет эффективно применять в повседневной
деятельности компании. При этом сама фирма продолжит нести убытки,
связанные с задвоением функций, которые бы могла выполнять комплексная ИС,
и обслуживанием сложных процедур обмена данными.
Автоматизация по участкам включает в себя процесс автоматизации
некоторых производственных или управленческих подразделений предприятия,
сгруппированных по функциональному признаку (к примеру, бухгалтерия,
канцелярия и т.п.). Автоматизация по участкам включает в себя отбор одного или
нескольких участков работ, а точнее, задач, выполняемых одним или несколькими
сотрудниками конкретного отдела без привязки к установленным в компании
бизнес-процессам. Такой способ характерен для отдельных случаев: объем
инвестиций компании недостаточен для полной автоматизации; есть участки, где
использование ИС дает видимый экономический эффект, к примеру, за счет
сокращения сотрудников; технология работы или иные условия не смогут
обходится без применения ИС. Для того, чтобы автоматизация по участкам стала
эффективной, необходимо создание стратегических и оперативных планов
автоматизации документооборота.
Автоматизация по направлениям деятельности, к примеру, управление,
производство, сбыт, контроль финансов и т.п. От автоматизации по участкам
отличается тем, что автоматизация по направлениям работ включает участие в
подобном процессе всех организационных подразделений, работа которых
связана с автоматизируемым направлением. Зачастую любое направление бизнес-
процесса охватывает почти все подразделения предприятия, именно поэтому
автоматизацию по направлениям не стоит рассматривать, как локальную.
Автоматизация по направлениям заключается в выборе автоматизации одного или
нескольких бизнес-процессов в полном объеме – от начала до конца, при этом
необходимо проведение реинжиниринга бизнес-процессов и разработки модели
документооборота всей компании. Для увеличения эффективности процесса
автоматизации по направлениям нежно разработать стратегический и тактический
планы автоматизации. Подобные планы должны быть пересмотрены после
завершения автоматизации отдельного бизнес процесса и оценки достигнутых
результатов.
Комплексная автоматизация предполагает внедрение ИС на все функции
управления и все бизнес-процессы компании за счёт изначальной интеграции на
этапе внедрения. Практическим результатом перехода к единой ИС становится
общий для всей компании стандарт на возможности взаимодействия
пользователей с системой (применение одних и тех же процедур обработки
документов, необходимых для составления различных управленческих решений).
Можно выделить некоторые особенности комплексного подхода к автоматизации
документооборота компании: увеличение экономической эффективности этого
подхода по сравнению с другими (по направлениям, по участкам); повышение
требований к качеству управления процессом интеграции системы. Определение
одной или комбинации из стратегий автоматизации документооборота выражается
результатом анализа текущего и предполагаемого состояния компании на
некоторый период. Данный подход очень дорог и длителен, поэтому, в силу
существующих экономических и временных ограничений, в данной задаче не
применим.
В исследуемом случае лучше всего подходит стратегия автоматизации по
направлению. Следовательно, предприятие сможет автоматизировать
деятельность по реализации учета рабочего времени, получив при этом
экономический эффект.
1.3.3 Выбор и обоснование способа приобретения ИС для
автоматизации комплекса задач
В этом разделе рассматриваются базовые возможные варианты
приобретения ИС для компании, а также описывается эффект от процесса их
внедрения, потенциально оказанный на саму фирму. Выявлены главные
недостатки и преимущества всех рассмотренных способов приобретения.
Сегодня есть несколько вариантов решения поставленной задачи, касаемо
приобретения:
• Покупка готового ПО;
• Покупка готового ПО и его модификация под требования клиента;
• Создание собственного ПО;
• Доработка уже имеющегося и находящегося в работе ПО.
Покупка готового ПО - один из наиболее простых вариантов, не требующих
других затрат, кроме финансовых. Среди преимуществ такого способа можно
назвать минимальные временные затраты и усилия на внедрение продукта. Также
есть очень большая вероятность купить хороший и актуальный продукт из
последних разработок, ввиду повышенной конкуренции на данном рынке.
Основными недостатками становится высокая стоимость, поскольку хороший
продукт не может стоить дешево, к примеру, те, что были рассмотрены в пункте
1.3.1 систем, и нельзя адаптировать систему под себя на 100%, даже применяя все
её функции по максимуму. Последним недостатком можно назвать возможность
возникновения критических ошибок из-за несовместимости системы и
структурной организации предприятия, для устранения которых будут нужны
немалые временные затраты, поскольку скорее всего придется обращаться к
производителю.
Покупка готового ПО и его модификация под требования клиента - это
улучшенный первый вариант приобретения, но с сохранившимся единственным
недостатком - это предполагаемая высокая стоимость. Такой вид приобретения
дает возможность в буквальном смысле «подогнать» все параметры ПО под
нужды потребителя и условия работы, что минимизирует вероятность реализации
критических ошибок. Но важно учитывать, что на слишком глубокие изменения
системы могут занимать значительные промежутки времени, т.к. разработчикам
компании необходимо будет понять код продукта.
Создание собственного ПО - самый длительный способ получения нужного
продукта. Группа специалистов IT отдела, отдела программных разработок
реализует свой собственный продукт для своей же компании, учитывая её
специфику. Но зачастую этот процесс занимает довольно много времени и не
всегда гарантирует 100% результат. В созданном продукте может быть масса
недоработок, которые необходимо будет устранять уже в процессе работы
системы. Хотя всегда есть шанс получить оптимальный для компании и ее бизнеса
продукт.
Доработка уже имеющегося и находящегося в работе ПО - обычная
модернизация уже имеющейся системы.
Выделив основные доступные варианты приобретения продукта, учитывая
специфику и возможности компании был выбран вариант создания
информационной системы своими силами.
1.4 Обоснование проектных решений
1.4.1 Обоснование проектных решений по информационному
обеспечению
Информационное обеспечение (ИО) подсистемы основано на
информационной модели работы сотрудников компании. Выделяют
внемашинное и внутримашинное обеспечение. Само ИО состоит из:
системы классификации и кодирования;
системы единообразной документации, применяемой в ИО,
информационную базу, т.е. совокупность данных из всех информационных
массивов.
Внемашинное обеспечение определяется всей совокупностью данных,
основную часть которых составляют документы. Выделяют первичные (входные)
документы, например, заявки пользователей, и отчетные (выходные) документы,
к которым относят документы по итогам рассмотрения заявок, отчеты и т.п.
Внутримашинное ИО отражает данные на машинных носителях в виде
специально организованных массивов (файлов), БД и их информационных связей.
Внутримашинное ИО подсистемы организует информационную среду,
способствующую выполнению сотрудниками своих профессиональных
обязанностей. Эта область определяется набором объектов, их свойств и
взаимосвязей. Для любого такого объекта выражается набор его характеристик,
свойств.
Информационные потоки внешнемашинного ИО определяются как
направленное постоянное движение документов от источника из создания к
конечному получателю.
В проектном решении применяются несколько принятых у заказчика
классификаторов, к которым относятся списки сотрудников, должностей, отделов
и графиков работы. При этом требуется использовать справочники: линейные и
иерархические. В линейных справочниках все элементы, включенные в состав,
описаны в виде классических списков, а в иерархических – имеют вид списков с
иерархической структурой.
Выделим требования к системам кодирования и классификации данных.
Системы классификации (СК) можно разделить на иерархические и
многоаспектные. Иерархическая СК включает в себя разбиение начального
множества на отдельные подмножества, между которыми есть отношения
подчинения друг другу. В многоаспектных СК использованы параллельно сразу
несколько независимых классификационных признаков, т.е. начальное
множество описывается сразу в разных аспектах. Поскольку данные не нужно
классифицировать по нескольким признакам, в проектном решении будет
использоваться иерархическая система.
Унифицированная система документации (УСД) является грамотно
организованным комплексом объединенных документов, отвечающим
совокупным правилам и требованиям и включающим данные, требуемые для
управления отдельными экономическими объектами. [7]
При реальном проектировании реализуется целый цикл разработки ИС и
создания программных модулей. Подобный подход становится достаточно
дорогим и выбор его оправдан в отдельных случаях:
• Создание полностью новой ИС;
• Неимение доступных прототипов ИС;
• Подготовка малых ИС с минимальным числом функций;
• Работа опытных разработчиков в самой компании.
Электронная форма документа – это некий шаблон с пустым
пространством, которое оставлено для самостоятельного заполнения
пользователем. Подобные формы включают в себя командные кнопки, меню,
формы и поддерживают разнообразные виды входных данных. Важно понимать,
что для реализации подобных форм необходимо узконаправленное ПО.
Определим часть форм:
• Формы для сбора данных, переноса их в БД с возможность обработки
(перемещение и сбор по e-mail, через формы на самих Web-серверах);
• Формы для получения и сбора данных внутри компании и за ее
пределами (заказы на покупку, отчеты о расходах в командировках, счета).
В системе учета рабочего времени применяются оба типа электронных
форм.
Информационная база (ИБ) является некой совокупностью данных,
организованной конкретным способом и помещённая в память вычислительной
системы под видом файлов, с помощью которых реализуются потребности в
данных для управленческих процессов и решаемых задач.
Есть несколько вариантов реализации информационной базы: группировка
локальных файлов и объединенная информационная база, контролируемая СУБД
[15].
Локальные файлы поддерживают оперативную обработку данных, но из-за
огромного числа дублированных данных, сложности доступа к ней это становится
несущественным. Поэтому хранение локальных файлов требуется только в
отдельных приложениях, которые нуждаются в повышенной скорость передачи
при импорте информации.
Интегрированная ИБ – объединение взаимосвязанных данных с малой
избыточностью, допускающей их применение оптимальным образом для
большинства приложений.
СУБД поддерживает совместимость данных, минимизацию
синтаксической и семантической избыточности, совмещенность данных и
реального состояния объекта, разделённое хранение информации у
пользователей. Нюансом можно отметить требование повышенного контроля
вводимых данных и разделение доступа к данным.
В качестве ИБ выбирается интегрированная БД под контролем СУБД.
Документооборот в компании довольно большой, документы дублируются и
корректируются много раз. Пользователям нужна актуальная информация с
периодическим обновлением, а группа локальных файлов не дает такой
возможности.
Существуют насколько вариантов реализации организации данных в БД:
• Иерархическая модель;
• Сетевая модель;
• Реляционная модель.
Взаимосвязь в иерархической модели реализована совокупностью
структурных данных, где тип сегмента потомка связывается лишь с одним типом
сегмента предка. Подобная модель имеет ряд нюансов, к примеру, отсутствие
явно определенного разделения физических и логических параметров модели.
Для выявления неиерархических отношений нужны другие действия. Неявные
запросы потребуют перестроить саму БД.
Сетевая модель – переданные данные сетевыми структурами типов записей
и совокупных отношений «один к одному» или «один ко многим».
Реляционная модель реализует и представляет информацию в виде таблиц
и реляций. Все отношения тут имеют свой личный ID, что помогает
минимизировать повторяющиеся данные. Такие модели легки в применении,
просто переделываются и их реализация не требует больших временных затрат.
Есть 2 подхода к проектированию реляционной БД:
• В процессе создания концепции реализуется не концептуальная
модель данных, а сама реляционная схема БД, включающая определения
реляционных таблиц, требующих нормализации;
• Функциональная модель переделывается в нормализированную
реляционную. Подобный подход часто можно встретить при создании больших
БД для крупных ИС.
Исходя из описанного выше делаем выбор в пользу реляционной БД, она
просто трансформируется, удобна в применении и несложная по своей структуре.
В процессе создания системы нужно использовать реляционную модель
БД. Реляционная модель данных отдельной предметной области включает в себя
набор отношений, меняющихся во времени. В процессе разработки ИС
совокупность отношений дает возможность хранить данные о всех объектах
предметной области, отражать связи между ними. При этом сами данные
сохраняются в таблицах. Для простоты определения каждая таблица
реализованной БД имеет уникальный код.
К ИО предъявляются указанные ниже общие требования:
• ИО должно быть достаточным для реализации всех
автоматизируемых функций объекта;