Current Situation
YongAn provides continuous care using day, evening, and night shifts. The current process uses a mixture of spreadsheets, paper records, and phone messages. Employee details, certification expiry, availability, time-off requests, schedules, and worked hours are not managed as one connected set of information.
This creates several problems. A manager may prepare a schedule without seeing a recent availability change. Printed or shared schedule files can produce multiple versions. Certification information may be checked separately from the schedule. Shift changes require additional calls, and attendance information must later be summarized for hours and overtime.
The main business problem is therefore larger than creating a calendar. The system needs to connect employee status, qualifications, availability, requests, assignments, and attendance so that staffing decisions use current information.
Proposed Process
The proposed system will use a draft-and-publish workflow. A manager can create and revise a draft schedule while the system displays assignment conflicts and coverage warnings. Before publication, the server checks the current database state again. Employees only see the published schedule.
Employees can enter their regular availability and temporary unavailable periods. They can submit time-off requests for manager review. Published shifts can be posted as open when additional coverage is needed. Employees can respond to open shifts or request a swap, but the schedule changes only after the required approvals.
Attendance begins with a published assignment. The employee records actual clock-in and clock-out times, while the original scheduled times remain unchanged. Managers can correct an attendance record with a reason. Completed records provide weekly hours and overtime information.
Actors and Responsibilities
The administrator controls accounts and reference information. The manager owns operational decisions such as publishing schedules, approving requests, assigning staff, and correcting attendance. The employee controls personal availability and requests but cannot view private records belonging to other employees.
These responsibilities define the system boundary. The application manages staffing information, but it does not contain resident or medical records and does not calculate payroll amounts.
Workflow Analysis
Schedule creation is the central workflow. Assignment validation should occur in a consistent order:
1. Confirm that the employee and schedule are active and editable.
2. Check for overlapping assignments.
3. Check the required rest period.
4. Check approved time off and recorded unavailability.
5. Check expected weekly hours.
6. Calculate minimum staffing and certification coverage.
The same assignment rules should be reused for direct assignment, open-shift approval, and shift-swap approval. Otherwise, one workflow could accept an assignment that another workflow would reject.
The schedule has draft and published states. A draft can contain warnings while the manager is still working. Publication is a controlled transition that requires another validation. Request workflows also use explicit states such as pending, approved, rejected, cancelled, or awaiting manager review. These states preserve the history of a decision.
Data Analysis
The main data relationships connect employees to accounts, positions, certifications, availability, requests, assignments, and attendance. A schedule period contains shifts, and each shift contains assignments. Shift types define normal times, minimum staffing, and qualification requirements.
Historical integrity is important. Deactivating an employee must not remove previous assignments or attendance. Correcting attendance must not change the original shift. Changes to a shift type must not silently rewrite old schedules.
Feasibility and Risks
The project is technically feasible using a web client, application server, and relational database. It is operationally feasible because the workflows match tasks already performed by managers and employees. The largest risks are scheduling-rule errors, scope growth, delayed feedback, privacy mistakes, and insufficient testing.
The analysis confirms that the scheduling core should receive the highest priority. The next stage will convert these findings into the application architecture, database design, API, security controls, and interface design.