37
Hogan Develop – отчет, позволяющий определить перспективы
развития оцениваемых сотрудников;
Teams – отчет, позволяющий создать эффективную рабочую группу;
Hogan Lead – отчет, выявляющий сотрудников с лидерскими
способностями;
Safe System – отчет, показывающий достоинства и недостатки
архитектуры рабочих станций персонала и культуры компании.
Teams – отчет, позволяющий создать эффективную рабочую группу.
Одной из специфических особенностей данной системы является
разработанный опросник HBRI (Hogan Business reasoning Inventory) –
опросник для оценки навыков принятия управленческих решений [25].
Пример работы системы Hogan Assessment System (авторизация через
веб-интерфейс) приведен на рисунке 10.
Рисунок 10. Пример экрана системы «Hogan Assessment System»
Последней рассмотренной в данной главе системой является кадровая
система тестирования и оценки персонала «К-Фактор (HR1)», разработанная
израильской компанией Nemsysco. Данная система спроектирована для
38
служб безопасности, служб персонала, отделов кадров и кадровых агентств, а
также руководителей, принимающих ответственные решения по приему и
оценке кадров.
Темы тестирования персонала и блоки вопросов, подготовленные
специалистами производителя, заложены в систему и являются наиболее
актуальными для всех работодателей. В базовый тест входит пять тем, в
дополнение к которым можно выбрать еще одну или две темы из трех
предлагаемых системой оценки персонала. В перечень тем, включенных в
опросники системы «К-Фактор», входят:
лояльность по отношению к организации;
конфиденциальность и секретность;
добросовестность, профессиональная честность, благонадежность;
хищение у работодателя;
работа в команде;
склонность к взяточничеству и мошенничеству;
отношение к алкоголю, наркотикам и азартным играм.
Кадровая система «К-Фактор (HR1)» имеет специфическую
особенность – она оценивает не содержательную сторону ответов
тестируемого, а психоэмоциональные реакции головного мозга в ходе теста,
которые отражаются в его речи. Эти реакции измеряются соответствующими
датчиками и обрабатываются алгоритмами, разработанными и
запатентованными компанией Nemsysco.
Система «К-Фактор (HR1)» является достаточно интересной, но она
мало применима к рассматриваемой в данной работе задаче, поскольку
ориентирована исключительно на психологическое тестирование кандидатов
по общим важным личностным качествам, но не поддерживает проверку
профессиональных компетенций кандидатов, ведение базы данных
должностей, вакансий и требований к ним. Однако, по мнению автора,
данная система заслуживает особого внимания и рекомендуется для
39
использования кадровыми специалистами в качестве дополнительного этапа
при приеме работников в штат компании.
На рисунке 11 приведен пример работы кадровой системы
тестирования и оценки персонала «К-Фактор (HR1)».
Рисунок 11. Пример экрана системы «К-Фактор (HR1)»
По данным источника [13] стоимость лицензии данного программного
решения составляет 112100 рублей за 20 проверок.
В таблицу 2 сведены основные важные характеристики рассмотренных
готовых программных решений. Таким образом, на основании таблицы 2 и
проведенного исследования можно сделать вывод о том, что на рынке
программного обеспечения представлены готовые продукты, которые так
или иначе способствуют автоматизации рассмотренной задачи. Однако
большинство таких готовых решений ориентированы на общую задачу
управления персоналом в комплексе. Это определяет такие недостатки
данных готовых решений, как:
дороговизна приобретения;
трудоемкость адаптации и внесения изменений;
40
необходимость сложной и дорогой настройки системы уже после
приобретения;
необходимость сопровождения (скорее всего, на коммерческой
основе);
наличие множества дополнительных функций, которые не требуются.
Таблица 2
Основные функциональные возможности рассмотренных
продуктов
Требование/
Характери-
стика
1С:
Предприятие.
Оценка
персонала
SAO
HAS
К-Фактор
Стоимость
228 400 руб.
(10 активных
пользователей)
20 евро за 1
пользователя
в месяц
50-150 евро
112100 р.
за 20
проверок
Возможность
настройки
При выборе
конфигурации
-
Выбор типа
отчета
-
Возможность
расширения
функций
В соответствии с
прайсом 1С
-
-
-
Возможность
сопровождения
В соответствии с
прайсом 1С
Не требуется
Оговаривается с
разработчиком
Не
требуется
Обучение
использованию
В соответствии с
прайсом 1С
Руководство пользователя
Ведение базы
должностей
+
-
-
-
Ведение базы
вакансий
+
-
-
-
Управление
тестами для
кандидатов
+
-
-
-
Тестирование
кандидатов
+
+
+
+
(только
психологи
ческие
аспекты)
Учет
требований к
вакансиям
-
+
-
-
Возможность
самостоятель-
ного расшире-
ния функций
Программирован
ие функций на
встроенном
языке
Нет
Нет
Нет
41
1.3.2. Выбор и обоснование стратегии автоматизации задачи
Существует несколько типов стратегии автоматизации: по участку, по
направлению, комплексная и хаотичная.
В данном случае автоматизируется не какой-то участок компании, а
система учета и обработки вакансий, автоматизация тестирования
кандидатов в соответствии с требованиями\, предъявляемыми к этим
вакансиям. Таким образом, очевидно, что для автоматизации выбранной
задачи больше всего подходит стратегия автоматизации по направлению.
Автоматизация по направлению подразумевает под собой автоматизацию
отдельных направлений деятельности компании и предполагает участие в
этом процессе всех организационных подразделений, задействованных в
функционировании по автоматизируемому направлению. Направлением
автоматизации в данном случае будет – реорганизация системы учета и
ведения требований к вакансиям компании. Такой подход к автоматизации
широко применяется на практике и в дальнейшем интеграция уже
автоматизированных направлений в рамках всего предприятия не будет
связана с серьезными препятствиями.
Выбранная стратегия автоматизации предполагает выполнение
нескольких основных этапов:
Формирование целей и задач проекта. На этом этапе определяются
конкретные цели разработки системы и ставится комплекс задач, которые
она должна решить.
2. Разработка модели вариантов использования. Данная модель
разрабатывается для более предметного представления ИС при ее
проектировании. Модель вариантов использования (Use Case) позволяет
идентифицировать действующих лиц и назначить им функции системы.
В [20] отмечается, что модель вариантов использования системы может
выражать ее пользовательские требования. В [27] также говорится о модели
прецедентов как об одном из способов выражения требований к
42
программному продукту. Таким образом, модель вариантов использования
должна быть построена на первом этапе разработки системы и
использоваться для формализации функциональных требований. [14]
3. Формализация требований к информационной системе. Данный этап
позволяет систематизировать требования, предъявляемые к информационной
системе в виде единой модели.
4. Проектирование информационной системы. Процесс проектирования
включает создание необходимого и достаточного количества моделей
системы для ее полного описания с разных сторон – структурного,
функционального, информационного, объектного, компонентного. На этом
этапе также создается концептуальная и логическая модель базы данных
системы. Для проектирования программного обеспечения используется язык
визуального моделирования UML (Unified Modelling Language). UML – это
язык для определения, визуализации, конструирования и документирования
артефактов программных систем [29]. Моделирование на языке UML
производится с помощью специальных инструментов – CASE-средств,
большинство из которых поддерживают возможности Forward Engineering,
позволяющие генерировать шаблонные блоки программного кода по
визуальным моделям.
5. Реализация информационной системы. Данный этап заключается в
непосредственной реализации ИС в соответствии с разработанными на
предыдущем шаге моделями. Если на предыдущем шаге в качестве
инструментов проектирования использовались CASE-системы,
поддерживающие возможности Forward Engineering и Database Engineering,
то процесс реализации ИС может быть существенно упрощен, поскольку эти
возможности позволяют:
автоматически создать шаблоны классов объектной структуры
программного обеспечения на выбранном языке программирования.
43
автоматически создать исходный код формирования (создания) базы
данных на языке описания данных (DDL, Data Description Language) –
такой исходный код выполняется как обычный запрос в любом
менеджере СУБД, в результате чего создается заранее
смоделированная структура БД (таблицы, представления, триггеры,
ограничения целостности и т.д.).
6. Любая из ошибок программирования, которая не обнаруживается на
этапах компиляции и компоновки программы, в конечном счѐте может
проявиться тремя способами: привести к выдаче системного сообщения об
ошибке, «зависанию» компьютера и получению неверных результатов [4].
Для предотвращения таких ошибок, а также для оценки достоверности
получаемых результатов проводится процедура тестирования и отладки
программного продукта. На этапе тестирования проверяется не только
правильность работы программы, но также и ее устойчивость – величина,
характеризующая способность программного продукта сохранять
нормальную работоспособность при отклонении условий функционирования
различной степени [17] (например, ввод некорректных данных).
7. Последним этапом является сопровождение программы. Чтобы
обеспечить возможность быстрой модификации программного продукта,
программа должна быть построена по модульному принципу с хорошо
продуманной структурой, чтобы внесение дополнительных функций в
программу было возможно с наименьшими изменениями в структуре.
1.3.3. Выбор и обоснование способа приобретения ИС для автоматизации
задачи
Приобретение ИС может быть выполнено одним из следующих
способов: покупка готового решения, покупка готового решения с
последующей доработкой, собственная разработка.
Готовые решения, как правило, выполнены с высокой степенью
универсальности, чтобы охватить как можно больший сегмент. Это приводит
44
к недостаткам использования готовых решений, т.к. некоторые функции
альтернативных программных продуктов не будут востребованы для
конкретной задачи, что делает приобретение такого программного продукта
будет экономически не выгодно.
Если выбирать между приобретением готового решения с его
последующей доработкой и разработкой собственного решения с нуля,
оптимальным будет второй способ. Доработка готовых решений потребует
продолжительных временных затрат на изучение и подробный разбор
архитектуры и программного кода существующей системы. Также сложно
будет внедрить в существующую архитектуру собственных функций без
существенного нарушения стабильности системы, а высокая
универсальность может сильно затруднить понимание целостности системы.
Разработка нового программного решения с нуля в данном случае
имеет существенные преимущества, поскольку позволит с самого начала
разработать четкую модель требований к системе и неукоснительно ей
следовать, разработать свою понятную модульную архитектуру для
возможности последующей доработки.
Таким образом, способом приобретения ИС выбрана разработка новой
системы автоматизации ведения базы должностей с указанием требований к
ним посредством создания и ведения профориентированного тестирования
кандидатов (Vacations of Posts with Requirements by Testing – «VPRT»).
1.4. Обоснование проектных решений
1.4.1. Обоснование проектных решений по информационному
обеспечению
Основная цель проекта автоматизации – разработка информационной
базы данных вакансий с учетом возможности разработки учета и проверки
требований к ним. Таким образом, информационные массивы, которые
потребуется хранить и иметь к ним оперативный доступ, могут содержать
большое количество данных. Поиск и организация большого объема данных
45
может потребовать значительных вычислительных мощностей. Поэтому для
обеспечения автоматизируемой задачи наиболее оптимальной организацией
информационного обеспечения ИС «VPRT» будет централизованная база
данных с клиент-серверным доступом. При этом для БД следует выбрать
реляционную модель. Реляционная модель данных имеет ряд определяющих
преимуществ [19]:
гибкость структуры;
независимость наборов данных;
безопасность информации;
простота практического применения и использования;
простота понимания и реализации;
поддержка инструментов обеспечения целостности данных (каскадное
удаление или изменение, и т.д.).
Доступ к информационным таблицам БД ИС «VPRT» должен быть
организован в прикладном программном обеспечении с использованием
современных технологий. Средства СУБД должны обеспечивать целостность
данных, поддерживать триггеры и хранимые процедуры для их применения с
целью снизить нагрузку на прикладное ПО.
Современные системы разработки приложений предлагают множество
технологий для организации обмена с данными.
ODBC (Открытый интерфейс взаимодействия с базами данных - Open
Database Connectivity) – наиболее ранняя из известных технология, что не
мешает ей оставаться очень популярной среди технологий от Microsoft.
Позволяет приложению взаимодействовать с различными СУБД, при этом не
зависимо от используемой СУБД, что обеспечивается за счет специальных
библиотек доступа к данным (провайдеров) конкретных СУБД.
OLE DB [10]. Является результатом прогрессивного развития
технологии ODBC. Работает через интерфейсы объектных моделей
46
компонентов (COM). Основные же принципы работы технологии остались
теми же – поддержка работы с помощью провайдеров.
DAO (Data Access Objects - объекты доступа к данным) [8]. Изначально
технология являлась COM – интерфейсом для доступа к БД Access и
другими, поддерживающими ODBC. В данный момент технология считается
устаревшей.
ActiveX Data Objects (ADO - объекты для доступа к данным) [9] –
наиболее популярная (после ODBC) технология, которая обеспечивает
программируемую модель высокого класса. Является перспективной.
Большое достоинство этой технологии - поддержка объектов для доступа к
данным из скриптовых языков, таких как VBScript или Jscript, что составляет
определенную значимость технологии в контексте разработки web-
приложений.
ADO.NET [28] – представляет собой абсолютно независимую (от ADO)
технологию, заложенную в .NET Framework. ADO.NET – имеет множество
качественных улучшений ADO при использовании в создании
распределенных приложений. Предоставляет возможности интерфейса для
прикладного программирования приложений любой сложности, в том числе
и распределенных.
Применяемые в ИС «VPRT» классификаторы предназначены для
идентификации записей, организации учета справочников, тестов и
тестирований, обеспечения связывания данных в составе базы данных.
Используемые классификаторы являются локальными в пределах
информационной системы, имеют линейную систему классификации с
порядковым кодированием. Порядковые номера присваиваются средствами
автоматического инкремента счетчика записей, который должен
поддерживаться СУБД.
Так, состав информационного обеспечения ИС «VPRT» определяется
набором: