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

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

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

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

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

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

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

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

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

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