Prototype 2

PROTOTYPE 2 (Next Phase)

Because my project is intrapreneurial, the prototype I have designed and worked with is production ready. Since the initial inception of this prototype, I have been having weekly meetings with the two groups I have been working with, Hospital Billing and Emergency Department. These meetings have led to incremental changes within the initial build to 1) make it more efficient, 2) add more content, and 3) make the model clearer to end users.

Feedback from my pilot groups have been extremely positive, users who have been active with the prototype have already been using it for business decisions and reporting. As the models became more focused on their interests, their ability to use the prototype expanded greatly. Through this process though I have identified some challenges that will need to be addressed:

CHALLENGES:

  • Self-Reporting has turned out to be a much more challenging concept to teach. In the current state, data is curated and aggregated by a data analyst for our end users to consume. For people to be effective with Self-Reporting analytics it requires the user to have a much deeper understanding of their respective data, the operations of their department, and how to use this knowledge to bring out the analytics they are asking for.
  • Though I have buy-in from leadership for this endeavor, finding end users who can learn how to self-report and who have enough of an understanding of their operations and data has been challenging. In our current environment I feel that less than 10% of our workforce that uses analytics in their job will be able to use this tool efficiently.
  • My analytics experience within Health Care has been focused on Hospital Billing. Working with the Emergency Department has been a challenge for me as I am not as familiar with that data model. Engaging other build team members to help me construct new cubes, manage meetings, and validate build has not been an option. Workloads on our reporting team have been overwhelming so internal support is a challenge.
  • We have been unable to engage our system database architects to help us streamline our server configuration. Our DBA team is in a reactive and not proactive state, engaging them to help properly tune our servers is a continuing problem.
  • I am burning out on this project. Overall, I have spent a few years studying the cubes (self-reporting tool) build and configuration and in the last year I have been pushing hard (and failing) to get traction on self-reporting. With the start of this class things finally came together and I was able to get a good group of people to finally pilot these solutions. Though I am proud of the work I have done and feel good about the success of the two prototypes I have built, I find myself lacking the motivation to continue.

PIVOT/CHANGE POTENTIAL:

  • Because of my burnout, the first pivot option I am dealing with is to just quit. I do not know that I want to spend the next few years building out these solutions with the lack of internal support to help build, train, and enhance the experience for our end users. I still feel like this is the right solution for our company, but our organization does not seem to be at a point where pivoting to self-reporting is seen as a benefit. Though we in reporting see it as one, convincing the organization to take this route will require a culture shift. Assuming I can work through the burnout, the following changes should be considered:
  • We need to change our hiring process to allow us to find more data savvy/experienced users to bring into our organization.
  • We should consider smaller ‘shadow’ reporting groups that would be embedded in each department. These reporting groups will not be true report builders (i.e., they will not be using SQL) but rather they will be data knowledge experts in their area who can take our self-reporting tools and build custom dashboards/reports to drive the organization.
  • To expand this program more of the report developers will have to take an interest in building out these self-reporting tools. So far this has been a challenge for reasons that might not be obvious. The main hurdle to building these tools is that report developers do not use these tools to build reports or get data. The effort to get the tools up and running is large and the ‘glamour’ of building these solutions is turning out to not be of interest to most developers.
  • Ultimately, we are at a point where the company needs to decide whether they want to go forward with this self-reporting journey. If they do, we will need more resources committed to not only build and design, but also training and documentation. Overall, I think this project has proven that self-reporting can be a great tool for success for our organization and now we are at the point that a commitment must be made to either continue down this path or not.