Project Plan, Meeting Notes and Current Stage

Project Goals and Objectives

The core objective of this project is to improve the systems of rostering across Disability Service. It can be split into the following sub-objective.

a.       Review rostering systems across DS, especially the management time taken in developing monthly rosters

b.      Review IT programs related to rostering across DS. Clarify capabilities of Diverse IT programs in DS not fully understood or integrated.

c.       Comparative analysis of existing rostering system and those available in the marketplace

d.      Analyse and identify deficits in the IT area to generate rosters for improved work practices, match between skill sets and work needs, and client safety.

e.       Develop recommendations for improving the generation of rosters in DS accommodation services to support client, organisation and staff needs.

f.       Present outcomes and recommendations to the Accommodation executive.

Project Milestone

The whole project can be divided into phases:

Phase I       Understanding the current system and operation (Interview)

Phase II      Describe the current system and operation (Documentation)

Phase III     Understanding client’s expected system (Interview)

Phase IV      Searching for available purchase options to fill in the gap (Research)

Phase V        Analyzing the advantage/disadvantage of each option

Phase VI       Describe the analysis (Documentation)

Phase VII      Presentation

Schedule

Period	Job	Deliverable
Week 6, Oct 8th	Interview with all parties involved	Interview notes (See Appendix I)
Week 7, Oct 15th	Current situation description and analysis (documentation)	Description of current system and operation
Week 8, Oct 22th	Further Interviews (if necessary), with all parties involved	Interview notes and Refine current system document
Week 9, Oct 29th	Searching for available purchase options in the market;	Description of expected system and operation
Week 10, Nov 5th	Put forward solutions and substantiate each of them.	Brief report
Week 11, Nov 12th	Analysing advantage/disadvantage of each option	Brief report
Week 12, Nov 19th	Interview with all parties involved to get their opinion, writing analysis report	Interview notes, outline of final report
Week 13, Nov 26th	Writing analysis report	Final research report

Oct.12th Meeting Notes

Title: Exchange information got from interviews

Time: 6: 30 - 8:00 pm

Attendees: all expect Qiulu

Note taker: Tanya

Topic：

1. Information exchange and interview summary 

Judy and Tanya shared information got from Keith (KRONOS System Administrator) that: 

   (1) KRONOS is chosen by the government

   (2) KRONOS keeps the information of all the staff under DS accommodation service. There are about 2,500 staffs. All most 2,000 of them have fix rosters.Other teams, like Highgate park, has about 500 staffs need to have their rosters re-generated per month according to their needs and preference.

   (3) KRONOS can have changes. Keith can help us contact relevant technician if we need to build an interface between different system or integrate a roster-generating modular into it. 

And we got a HANDBOOK for further study in KRONOS's function and role within DS. 

Darren and Mark talked with the IT consultant who provide the following information:

   (1) The SALEFORCE system keeps information of real-time available staffs and vacancy situation of different work sites. It can be used to book staffs to fill vacancies.

   (2) SALEFORCE is a framework and it can be adjusted to fulfill needs easily. 

   (3) The IT consultant has developed a similar bus system. We can give a rostering document to him and let him check whether they work in a similar logic and whether we can automatically generate rosters using this existing bus system by making minute changes to it. 

2. Recommendation Brainstorming & Assignment for next week

According to the information we have now, we put forward three potential choices to address the rostering problems within DS accomodation service.

  Choice 1: Customize KRONOS  

  Assignment: KRONOS description (KRONOS HANDBOOK) -- Judy

  Choice 2: Customize SALEFORCE (IT consultant: Bus system)

  Assignment:

        1. roster document – how the rosters are generated? (Darren & Gillian)   
           another interview with IT consultant? 

           Can the Bus system work? 
           Can the system communicate with KRONOS?

        2. SALEFORCE Description (Mark, Akwasi)

   Choice 3: Find independent rostering system and develop interface between current systems

   Assignment:  Search the existing rostering system (Qiulu)

Interview with SA Disability Service staffs

Our project is to help South Australian Disability Servive(DS) get a rostering system that meet their needs. DS does not have an rostering system that can generate rosters for permanent staff automatically. And their online system to select available casual staff to fill vacancy for planned and unplanned leave can't take into account of clients needs, different awards and staff requests all together.  

As the first group on Monday has got the needs from Highgate Park centre, today we met staffs in the Business Compliance Unit (BCU) at Oakden.

We got some information from them.

1.       Highgate primary care center is an accommodation service belonging to Disability and Domiciliary Care Services. They have other accommodation service centers around SA like Highgate. Each of them is running by different team. Their functions are almost the same.

In total, there are about 15, 16 separate teams who work independently with each other. In most cases, each team will have 50 clients and 8-10 houses (worksites). Each team has a fixed group of staffs and they make its own roster independently within its own staffs for its houses. Each house has its own requirements. 

The team is divided geographically and clients with the same needs tend to be gathered together, such as clients with intellectual disabilities are in one worksite, clients with certain level of physical disabilities is gathered in one house.

If we can find the way to solve the rostering problems of Highgate, the same pattern can be applied to other teams.

2.       The BCU department we visited today is working for all the different teams to give them a replacement staff when they can’t find its own staff to take a certain shift (such as Highgate need one more PSW who can go to Ward 3A from 7 to 15 on Tuesday, 9^th Oct.).

The replacement staff is coming from two different sources. One is its own replacement staff pool, which has about 150 staffs. The other is agency. They have 3 contracted agencies they can turn to help if they need more people to work.

The replacement staff is arranged in two different ways -- monthly and daily. Most of the roster of each team is rearranged monthly. So once the roster of next month has been generated, the team may know if they need extra staffs on certain days of next month. Then they call the BCU center and book for the staffs they need. Then some of the replacement staffs are booked monthly. Those who have not been booked are available for daily assignment.  Each of the replacement staff has a nominated working day such as Wednesday and Thursday. Normally, they know that they have to work on these two days but don’t know the worksite they are going to work. For Wednesday, they may receive calls from BCU on Tuesday night or Wednesday morning (6 AM) to inform them their worksite for replacement of staff on sick leave or any other emergency.

Occasions that BCU has surplus replacement staff is very rare. Mostly all of its staffs have been assigned to certain place and they need to book staffs from agency almost every day.

They have an independent Replacement Staff System for booking and checking replacement staffs. It works well.

  

3.       After replacement has been placed and recorded in the system mentioned above. This roster changes should be inputted into KRONOS. In fact, KRONOS is a payroll system to generate payment instructions which are implemented by CHRIS. So KRONOS has all the actual roster information of different staffs from all teams as well as these replacement staffs from BCU.

4.       As Les Rowe said today, KRONOS cannot generate rosters. You should manually input existing rosters into it for payroll. It can be input by day or by fixed roster pattern (like Tuesday 7 to 15 per week from 10th Oct to 10th Nov.) Any changes in real work should be input into KRONOS or it can’t be paid correctly.

5.       Not all worksite has a swipe card system, actually only a few teams have as it is mentioned today. The others are working in timetable and adjustment log checking pattern. It works well and they may don’t have budget to install swipe card system in all the worksites. Besides, Highgate is their largest accommodation service center.

6.       They recruit people constantly as the work force shortage. And they have training processes for new staffs. 

7.    I drew a picture of current systems worked for roster. As those we interviewed today, KRONOS, CHRIS and the replacement systems can’t be changed. We should search for a new system that meets its requirement as generating rosters automatically.

EA frameworks

As we all know, there are four main frameworks (Zachman, TOGAF, FEA and Gartner) which are frequently adopted by enterprises now. Many comparisons have been made between the four frameworks. And certainly each of them has its own pros and cons and applied occasions. This week I have explored and studied the most popular frameworks, which, fortunately, can be used together in building up an Enterprise Architecture.

Zachman

As it is shown in the following picture, Zachman gives you a overall picture (what, how, where, who, when and why) of the enterprise from different perspectives(scope, business model, system model, technology model, detailed representations) for different stakeholders(planner, owner, designer, builder, subcontractor).

Horizontally, it's a complete description of the enterprise for certain stakeholder.
Vertically, it is the different representations of the same thing accomplished by different actors within the enterprise.

In this way, we can easily identify the gaps between different stakeholders which help us to fix them. And every level of the enterprise can align with each other and have a clear understanding of their current situation.

The most important thing for you to understand Zachman is that it is not a methodology but taxonomy. It doesn't give you the way on how to analyze or get the information of each cell but a guide of what kind of information you need to find and how to organize it in a picture that make the gaps more explicit.

Different kinds of artifacts are listed in each cell of the picture above, which can be used as the method to solve the certain issue.

TOGAF

The following video gives a brief introduction of TOGAF.

TOGAF gives a process and methods to develop Enterprise Architecture. It is easier for enterprise to implement and there are plenty of supported software to work on to build up an Enterprise architecture under TOGAF framework. 

Zachman is a static descriptive view of the whole enterprise, while TOGAF is a dynamic process for EA development. Supported by the Open group, there are great quantities of detail practicing examples on their website. 

By following the steps, enterprise can not only figure out their business architecture, application architecture, data architecture and technical architecture but also find solutions and implementation & maintenance plan for future strategic transformation.

Here is a specific example in using TOGAF in EA development. In contrary to theoretical description, this video shows how the phrased mentioned before be articulated by certain artifacts, which gives me a practical idea about TOGAF.

Besides, this week I read that EA is specially needed by those who are facing business transformation or radical infrastructure change. In this case, the stakeholders can greatly gain from identifying and refining their requirements, showing how this requirement be addressed and what kind of trade-offs will be made in order to get these.