Готовый дипломный проект — разработка АИС учета ПК и оргтехники на базе 1С

Введение

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

Целью настоящей дипломной работы является разработка специализированного программного модуля для автоматизированной информационной системы (АИС) на базе платформы 1С:Предприятие 7.7, предназначенного для комплексного учета процессов, связанных с ПК и оргтехникой на предприятии.

Для достижения поставленной цели были определены следующие ключевые задачи:

1. Провести всесторонний анализ предметной области, включая изучение существующих бизнес-процессов и выявление их недостатков.
2. Спроектировать архитектуру и базу данных будущей автоматизированной системы.
3. Осуществить программную реализацию разработанного модуля в среде 1С:Предприятие 7.7.
4. Провести тестирование функциональности модуля и рассчитать экономическую эффективность от его внедрения.

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

Глава 1. Аналитический обзор и постановка задачи

Раздел 1.1. Как устроен современный учет ИТ-активов на предприятии

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

• Регистрация и учет: Присвоение инвентарного номера каждой единице техники, фиксация ее характеристик и первоначальной стоимости.
• Отслеживание жизненного цикла: Мониторинг перемещений техники между подразделениями и материально-ответственными лицами.
• Плановое техническое обслуживание (ТО): Организация и контроль регулярных профилактических работ для предотвращения поломок.
• Ремонт: Фиксация заявок на ремонт, учет выполненных работ и замененных комплектующих.
• Инвентаризация: Периодическая сверка фактического наличия техники с учетными данными.
• Управление лицензиями ПО: Контроль за использованием лицензионного программного обеспечения.
• Расчет амортизации: Ежемесячное начисление износа в соответствии с бухгалтерскими нормами.

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

Раздел 1.2. Сравнительный анализ существующих решений и обоснование выбора платформы

Рынок программного обеспечения предлагает широкий спектр готовых систем для управления ИТ-активами (IT Asset Management, ITAM). Их можно условно разделить на несколько категорий, каждая из которых имеет свои преимущества и недостатки. Для обоснования выбора платформы разработки проведем их сравнительный анализ.

Сравнительный анализ платформ для разработки АИС

Платформа	Преимущества	Недостатки
Крупные ERP-системы (SAP, Oracle)	Комплексный подход, высокая надежность, интеграция со всеми бизнес-процессами.	Очень высокая стоимость владения, сложность внедрения и настройки, избыточный функционал для узкой задачи.
Свободное ПО (GLPI, OCS Inventory)	Нулевая стоимость лицензий, открытый исходный код, активное сообщество.	Сложность интеграции с бухгалтерскими системами, требует высокой квалификации для поддержки, отсутствие официальной ответственности.
1С:Предприятие	Широкая распространенность, наличие множества специалистов, гибкость настройки, легкая интеграция с бухгалтерией, умеренная стоимость.	Версия 7.7 является устаревшей, но все еще широко используется и достаточна для данной задачи.

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

Раздел 1.3. Формирование и детализация требований к автоматизированной системе

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

Функциональные требования (что система должна делать):

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

Нефункциональные требования (как система должна работать):

• Надежность: Система должна обеспечивать сохранность и целостность данных.
• Безопасность: Необходимо разграничение прав доступа пользователей к данным и функциям системы.
• Производительность: Время отклика на действия пользователя не должно превышать установленных норм.
• Удобство интерфейса: Интерфейс должен быть интуитивно понятным для пользователей с разным уровнем подготовки.

Требования к данным: Система должна оперировать сущностями «Техника», «Комплектующие», «Сотрудники», «Подразделения», «Документы» с соответствующими наборами атрибутов. Для описания взаимодействия пользователей с системой была разработана модель вариантов использования (Use Case), которая наглядно демонстрирует основные сценарии работы. Сформулированные требования являются прямым руководством к действию на следующем, проектном этапе работы.

Глава 2. Проектирование архитектуры и компонентов системы

Раздел 2.1. Разработка архитектуры будущей информационной системы

Для разрабатываемой АИС была выбрана классическая двухуровневая клиент-серверная архитектура, которая является стандартом для решений на платформе 1С:Предприятие 7.7. Такая архитектура оптимально подходит для поставленной задачи, обеспечивая централизованное хранение данных и разделение логики.

Система состоит из трех основных компонентов:

1. Клиентское приложение («Толстый клиент»): Это исполняемая среда 1С, которая устанавливается на рабочие места пользователей. Она отвечает за отображение пользовательского интерфейса (форм, отчетов) и выполнение части бизнес-логики на стороне клиента.
2. Сервер Базы Данных (СУБД): Центральный компонент, отвечающий за хранение всей информации в структурированном виде, обеспечение целостности данных и обработку запросов от клиентских приложений. В контексте 1С 7.7 это, как правило, файловый режим или Microsoft SQL Server.
3. Бизнес-логика: Алгоритмы, реализованные на встроенном языке 1С, которые описывают правила обработки данных (например, логика проведения документов). Эта логика частично выполняется на клиенте, а частично — в виде хранимых процедур на сервере СУБД.

Схема взаимодействия проста: пользователь через клиентское приложение выполняет действие (например, заполняет документ «Списание»). Клиентское приложение формирует запрос к серверу БД. Сервер обрабатывает запрос, изменяет данные и возвращает результат, который клиентское приложение отображает пользователю.

Выбор данной архитектуры обусловлен ее надежностью, проверенной временем, и полной поддержкой со стороны платформы 1С. Определив общую структуру, необходимо детализировать ее важнейший компонент — базу данных.

Раздел 2.2. Проектирование логической и физической структуры базы данных

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

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

• Сотрудники: Хранит информацию о материально-ответственных лицах.
• Подразделения: Описывает структуру организации.
• Номенклатура: Справочник видов техники и комплектующих.
• ОсновныеСредства: Основной объект учета, содержащий информацию о каждой единице техники (инвентарный номер, стоимость, дата ввода).
• Документы: Сущности, фиксирующие хозяйственные операции («Поступление», «Перемещение», «Списание»).
• Заявки: Сущность для учета обращений на ремонт и обслуживание.

2. Разработка даталогической (реляционной) модели. На основе ER-диаграммы была спроектирована реляционная модель, готовая к реализации средствами 1С. Каждая сущность была преобразована в таблицу (в терминах 1С — Справочник, Документ или Регистр) с детальным описанием полей, их типов данных, первичных и внешних ключей. Например, для таблицы «ОсновныеСредства» были определены поля: `ID` (первичный ключ), `Наименование`, `ИнвентарныйНомер`, `ДатаВводаВЭксплуатацию`, `ПервоначальнаяСтоимость`, `ID_Сотрудника` (внешний ключ к таблице «Сотрудники»). В ходе проектирования были применены принципы нормализации для устранения избыточности и обеспечения целостности данных. Имея готовую структуру данных, можно приступать к проектированию логики, которая будет этими данными оперировать.

Раздел 2.3. Проектирование модулей бизнес-логики системы

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

Ключевые модули бизнес-логики:

• Модуль учета поступлений: Отвечает за оприходование новой техники. Алгоритм его работы включает создание записи в справочнике «ОсновныеСредства», присвоение уникального инвентарного номера, установку начального статуса «На складе» и формирование движений в регистре учета.
• Модуль внутреннего учета: Реализует логику перемещения техники и ее обслуживания. Алгоритм для документа «Перемещение» изменяет значения реквизитов «Подразделение» и «МОЛ» у соответствующей единицы техники. Алгоритм для «Заявки на ремонт» изменяет статус актива на «В ремонте».
• Модуль списания: Обеспечивает корректный вывод техники из эксплуатации. Его алгоритм включает проверку оснований для списания (например, акт технической экспертизы), изменение статуса техники на «Списано» и архивацию ее карточки для сохранения истории.
• Модуль отчетности: Содержит алгоритмы для сбора, агрегации и представления данных пользователю в удобном виде (например, алгоритм формирования инвентаризационной ведомости, который делает срез по остаткам на определенную дату).

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

Раздел 2.4. Проектирование пользовательского интерфейса и ролевой модели доступа

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

1. Проектирование UI. Были разработаны прототипы (макеты) всех основных экранных форм системы. Особое внимание уделялось интуитивной понятности и эргономике.

• Карточка техники: Форма, отображающая всю информацию о конкретной единице оборудования.
• Журнал документов: Единый интерфейс для просмотра и поиска всех операций (поступлений, списаний и т.д.).
• Форма заявки на ремонт: Простая форма для быстрой регистрации обращения в техподдержку.
• Окна отчетов: Интерфейсы для настройки параметров и вывода отчетов.

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

2. Разработка ролевой модели доступа (RBAC). Управление ролями критически важно для безопасности данных. Были определены следующие роли пользователей:

• Администратор: Полные права на настройку системы, управление пользователями и доступ ко всем данным.
• Кладовщик (МОЛ): Права на создание документов поступления, списания и перемещения техники.
• Сотрудник техподдержки: Доступ к модулю заявок на ремонт, возможность изменять статус техники («В ремонте», «Отремонтировано»).
• Обычный пользователь: Права только на просмотр информации о закрепленной за ним технике.

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

Глава 3. Программная реализация модуля в среде 1С

Раздел 3.1. Настройка среды разработки и создание объектов метаданных

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

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

1. Справочники: Были созданы справочники для хранения условно-постоянной информации: «Сотрудники», «Подразделения», «Номенклатура», «ОсновныеСредства». Для каждого справочника были настроены реквизиты (поля), их типы данных, длина и другие свойства.
2. Документы: Для отражения хозяйственных операций были созданы объекты типа «Документ»: «ПоступлениеТМЦ», «ВнутреннееПеремещение», «СписаниеТМЦ», «ЗаявкаНаРемонт». Для них были разработаны экранные формы и определен состав реквизитов «шапки» и табличной части.
3. Регистры: Для накопления информации в разрезе измерений был создан регистр остатков «УчетТМЦ», который позволяет оперативно получать данные о наличии техники на складах и у сотрудников.

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

Раздел 3.2. Программная реализация модуля учета поступления и ввода в эксплуатацию

Данный модуль автоматизирует один из первых и важнейших бизнес-процессов — оприходование новой техники. Центральным элементом модуля является документ «ПоступлениеТМЦ». Была разработана его экранная форма, позволяющая пользователю указать поставщика, дату, а в табличной части — список поступающей техники, ее количество и цену.

Основная работа была сосредоточена на написании программного кода на встроенном языке 1С в модуле проведения документа. При проведении документа «ПоступлениеТМЦ» система выполняет следующий алгоритм:

1. Проверяет корректность заполнения всех обязательных полей.
2. Для каждой строки табличной части создает новый элемент в справочнике «ОсновныеСредства».
3. Автоматически генерирует и присваивает уникальный инвентарный номер.
4. Формирует «приходные» движения в регистре «УчетТМЦ», увеличивая остаток техники на указанном складе.

Пример фрагмента кода (листинг):

// Фрагмент процедуры проведения документа "ПоступлениеТМЦ"
Процедура ОбработкаПроведения()
    // 1. Движение по регистру УчетТМЦ
    Регистр.УчетТМЦ.Склад = Склад;
    Регистр.УчетТМЦ.Номенклатура = Номенклатура;
    Регистр.УчетТМЦ.Количество = Количество;
    Регистр.УчетТМЦ.ДвижениеПриходВыполнить();
    
    // 2. Создание нового основного средства
    НовОС = СоздатьОбъект("Справочник.ОсновныеСредства");
    НовОС.Новый();
    НовОС.Наименование = Номенклатура.Наименование;
    // ... присвоение других реквизитов ...
    НовОС.Записать();
КонецПроцедуры

Кроме того, была реализована функция автоматического формирования печатной формы «Акт приема-передачи ОС (Форма ОС-1)», которая заполняется данными непосредственно из документа. Успешная реализация процесса «рождения» актива в системе позволяет перейти к автоматизации его «жизни» внутри предприятия.

Раздел 3.3. Программная реализация модуля перемещения, ремонта и обслуживания

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

Документ «Внутреннее перемещение» предназначен для фиксации передачи техники между подразделениями или сотрудниками. Его программная логика при проведении изменяет аналитические разрезы в регистре «УчетТМЦ»: формируется «расходное» движение по старому месту хранения и «приходное» — по новому. Таким образом, система всегда содержит актуальную информацию о том, где и у кого находится каждая единица оборудования.

Документ «Заявка на ремонт» служит для учета потребностей в обслуживании. Пользователь создает заявку, описывая неисправность. Сотрудник техподдержки, принимая заявку в работу, проводит ее. Программный код документа изменяет специальный реквизит-статус в карточке основного средства (например, на «В ремонте»). Это позволяет:

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

Механизм привязки техники к конкретному сотруднику реализован через реквизит «МОЛ» (материально-ответственное лицо) в регистре учета. Все листинги программного кода были снабжены подробными комментариями для пояснения логики их работы. Логическим завершением жизненного цикла является списание актива.

Раздел 3.4. Программная реализация модуля списания и расчета амортизации

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

Центральным объектом является документ «СписаниеТМЦ». При его проведении программный код выполняет следующие действия:

1. Формирует «расходные» движения в регистре «УчетТМЦ», полностью списывая остаточную стоимость и количество актива.
2. Изменяет статус основного средства на «Списано», исключая его из оперативного учета. Карточка актива при этом не удаляется, а переносится в архив для сохранения истории.
3. Генерирует печатную форму «Акт на списание основных средств (Форма ОС-4)».

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

• Выбирает все основные средства, находящиеся в эксплуатации.
• Для каждого объекта рассчитывает сумму амортизации за месяц, используя линейный метод (первоначальная стоимость / срок полезного использования).
• Записывает рассчитанные суммы в специальный регистр накопления «АмортизацияОС».

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

Раздел 3.5. Разработка системы пользовательских отчетов

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

Были реализованы следующие ключевые отчеты:

• «Инвентаризационная ведомость»: основной отчет для проведения инвентаризации. Он выводит список всего оборудования, числящегося за определенным сотрудником или в подразделении на указанную дату, с указанием инвентарных номеров и наименований.
• «Остатки на складе»: показывает, какая техника и в каком количестве находится на складах и не введена в эксплуатацию.
• «Техника на ремонте»: оперативный отчет для службы техподдержки, отображающий список всего оборудования, имеющего статус «В ремонте», с указанием даты начала ремонта.
• «История актива»: детальный отчет, который по инвентарному номеру показывает всю историю движения актива: поступление, все перемещения, ремонты и итоговое списание.

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

Глава 4. Тестирование и экономическая оценка проекта

Раздел 4.1. Разработка подробного плана и методики тестирования

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

Были определены следующие виды тестирования:

1. Модульное тестирование: Проверка корректности работы отдельных программных модулей (например, процедуры проведения документа «ПоступлениеТМЦ») в изоляции.
2. Интеграционное тестирование: Проверка правильности взаимодействия между различными модулями (например, корректность списания актива, который ранее был перемещен).
3. Системное (функциональное) тестирование: Проверка всей системы в сборе на соответствие функциональным требованиям, описанным в Главе 1.
4. Приемочное тестирование: Имитация работы конечных пользователей по заранее определенным сценариям.

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

Тест-кейс 1: Успешное создание и проведение документа «ПоступлениеТМЦ»
Предусловия: В справочнике «Номенклатура» есть позиция «Монитор Dell».
Шаги: 1. Создать новый документ «ПоступлениеТМЦ». 2. Заполнить шапку. 3. В табличную часть добавить «Монитор Dell» в количестве 1 шт. 4. Провести документ.
Ожидаемый результат: Документ успешно проведен. В справочнике «ОсновныеСредства» появился новый элемент. В отчете «Остатки на складе» количество мониторов увеличилось на 1.

Критерием успешного прохождения тестов являлось 100% совпадение фактического результата с ожидаемым. После планирования можно приступать к самому процессу проверки.

Раздел 4.2. Проведение функционального тестирования и анализ полученных результатов

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

Протокол функционального тестирования (фрагмент)

ID Тест-кейса	Ожидаемый результат	Фактический результат	Статус
TC-01	Документ «ПоступлениеТМЦ» проведен, остатки увеличены.	Результат соответствует ожидаемому.	Пройден
TC-05	Невозможно провести «Перемещение» без указания МОЛ-получателя.	Система выдала предупреждение, документ не проведен. Результат соответствует ожидаемому.	Пройден
TC-12	Отчет «Инвентаризационная ведомость» корректно формируется по данным регистра.	Результат соответствует ожидаемому.	Пройден

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

Раздел 4.3. Расчет прямых и косвенных затрат на разработку и внедрение

Технико-экономическое обоснование проекта требует точного расчета всех понесенных затрат. Они делятся на две основные категории: затраты на разработку и затраты на внедрение.

Затраты на разработку:

• Трудозатраты разработчика: Основная статья расходов. Рассчитываются как произведение количества часов, затраченных на анализ, проектирование, кодирование и тестирование, на часовую ставку специалиста-программиста 1С.
• Стоимость лицензий на ПО: В данном случае, так как использовалась имеющаяся у предприятия платформа 1С:Предприятие 7.7, эта статья затрат равна нулю.

Затраты на внедрение:

• Затраты на оборудование: Поскольку система разворачивается на существующей ИТ-инфраструктуре, капитальные затраты на закупку новых серверов или ПК отсутствуют.
• Затраты на обучение персонала: Включают время, затраченное специалистом на проведение инструктажа для будущих пользователей системы (кладовщиков, сотрудников техподдержки).
• Затраты на перенос данных: Включают трудозатраты на разработку утилит и ручной ввод начальных остатков из старых учетных систем (например, из Excel-таблиц).

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

Раздел 4.4. Расчет экономического эффекта и оценка рентабельности проекта

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

Прямой экономический эффект (экономия затрат):

• Сокращение трудозатрат: Автоматизация рутинных операций (формирование отчетов, актов списания, инвентаризационных ведомостей) высвобождает рабочее время сотрудников, которое можно оценить в денежном выражении.
• Уменьшение потерь от ошибок: Снижение количества ошибок при ручном вводе данных предотвращает финансовые потери, связанные с несвоевременным списанием или закупкой ненужного оборудования.
• Оптимизация запасов: Точный учет позволяет избежать закупки излишних комплектующих и техники.

Косвенный экономический эффект (улучшение качества управления):

• Повышение прозрачности учета: Руководство получает оперативный и достоверный доступ к информации о состоянии всего парка техники.
• Ускорение принятия управленческих решений: Быстрые и точные отчеты позволяют эффективнее планировать бюджет на обновление ИТ-инфраструктуры.
• Повышение контроля и ответственности: Четкая привязка техники к сотрудникам и подразделениям усиливает ответственность за ее сохранность.

На основе рассчитанных затрат и годовой экономии были определены ключевые показатели инвестиционной привлекательности проекта:

1. ROI (Return on Investment): Коэффициент возврата инвестиций, показывающий рентабельность проекта.
2. PBP (Payback Period): Срок окупаемости — период времени, за который доходы от проекта покроют затраты на него.
3. NPV (Net Present Value): Чистая приведенная стоимость, учитывающая стоимость денег во времени.

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

Заключение

В ходе выполнения настоящей дипломной работы были успешно решены все поставленные задачи и достигнута главная цель — разработка функционального программного модуля для автоматизации учета ПК и оргтехники на базе платформы 1С:Предприятие 7.7.

Основные выводы по результатам проделанной работы:

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

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

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