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

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

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


Если идти снизу вверх по описанию получается следующий набор листьевых функций (название-контроль-вход-выход-механизм):

1. запись клиента-данные записи(дата записи, ФИО, желаемые услуги), расписание мастеров и предоставляемые услуги, имеющиеся записи-нет-новая запись-Администратор

2. Изменение записи-данные новой записи, расписание мастеров и предоставляемые услуги, имеющиеся записи-старая запись-измененная запись-Администратор

3. Оказание услуг-запись-клиент до услуги-клиент после услуги с чеком, деньги в кассе, отметка о выполнении услуги мастером-Мастер, Администратор

4. Начисление ЗП мастеру-отметки о выполнении услуги мастером-нет-сумма ЗП-Директор

.......

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

ЗЫ.
ГОСТ позволяет включать в документацию схемы и документы в любых форматах по усмотрению разработчика. Иногда, правда, в пакет документации придется включить памятку "как читать диаграммы". Приведенное описание ближе всего к вариантам использования и удобнее всего было бы рисовать диаграмму вариантов использования. А приведенная специфика работы: короткие цепочки, множество преобразований над одним несчастным журналом удобна именно в вариантном описании.

Дык у нас маркетинговая революция - клиент-ориентированный подход на дворе.

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

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