Skip to main content

Tag: Methodologies

Oblivious or Attentive

I was once demoing the specific functionality of an application. I was looking forward to my favorite part of the meeting: Q&A, but to my surprise, no one uttered a word.  My mind was racing with questions: Was my delivery crystal clear that there were no questions?  Was no one paying attention? Why the silence? Should I have approached the demo differently? I earned great accolades relating to the demo. Yet, the silence was bothering me. When an attendee is quiet, does this translate as unplugged from the conversation? Or are they employing active listening? Let us analyze why the disconnect happens in the first place. Here are a few reasons:

  • Lack of a meeting agenda
  • The facilitator is over-communicating
  • Right people not in the meeting
  • The facilitator is deviating from the scope of the meeting
  • Attendees double-booked at the same time
  • Attendees distracted by things unrelated to the meeting
  • An email could have sufficed instead of a meeting
  • Topic covered in a previous meeting

 What would I do when I am not engaged in a meeting? I may:

  1. Multitask
  2. Stay quiet during the entirety of the meeting
  3. Browse on my smartphone
  4. Turn off my camera

 What would I do if I am engaged in a meeting? I may:

  1. Ask contextual questions based on the topic
  2. Volunteer to work on the action items
  3. Share one-off use cases or exceptions
  4. Assist in decision making
  5. Turn on my camera

Advertisement

What next?

The cues listed above are not a perfect indicator of engagement during a meeting but watch out for them. What strategy can you adopt during the next demo/meeting? As business analysts, we are Change Agents, experiment with the ideas mentioned below to lead the change:

  • Use virtual whiteboards and invite attendees to collaborate by sharing their ideas
  • Co-present instead of having one team member presenting through the meeting
  • Ask an open-ended question and ask every attendee to articulate their responses
  • Ask for votes from every attendee or create a survey with many options so that everyone can pick one

Conclusion:

Next time watch for those subtle or clear clues during a meeting. Lead meetings that best fit the target audience and are within the scope of the meeting agenda. It is motivating when attendees are not forced but are looking forward to the rendezvous.

“One of the greatest gifts you can give to anyone is the gift of attention” – Jim Rohn.

Where To Start with an Entity Relationship Diagram

In my previous article An Entity Relationship Diagram Isn’t Just For Database Design I talked about the usefulness of Entity Relationship Diagrams.

Richard Larson did an excellent overview of some of the more technical considerations when putting together an ERD For The Love Of Data

But one of my colleagues recently asked me for help, as they hadn’t done one before and weren’t even sure where to start. If you’ve no experience of putting together an entity relationship diagram, it can be quite daunting to take that first step.

As a consequence, I’ve put this together for the benefit of those who fall more into that “where do I start?” category, and to explain how you might start to document your ERD.

Continue reading

A Structured Approach for Providing Information Systems Solutions

The Information Systems Landscape Today

Arguably, systems built within the information technology industry have reached a certain level of maturity since their birth about 60 years ago.  Whether that maturity could be characterized as adolescence or middle-age is up for discussion.

Whatever the age level, we do know that there are myriads of solutions in the marketplace that satisfy many of the information management needs in many industries.  It is therefore imperative that any business in today’s marketplaces approach their quest for IT solutions in a methodical manner.

A Structured Approach to System Selection

In the Forefront of our Thinking…

SaaS or “Software as a Service” is the clarion call of IT applications today. This type of solution is owned, delivered and managed remotely by the providers themselves.  It offers many advantages over providing purchased or in-house developed solutions deployed on-premise. including [1]

  1.      A lower cost of entry – SaaS affects both hard costs (eliminates buying and provisioning hardware resources and allows for less staffing overhead) and soft costs (reduces opportunity cost lost due to the time it takes to implement a new system).
  2.      A reduction in the time to benefit/rapid prototyping – SaaS software applications are already installed and configured, thus reducing the time needed to turn up the software solution and facilitating prototyping efforts.
  3.      Scalability and a pay-as-you-go cost model – SaaS solutions usually offer predictability for both the subscription and, to some extent, administration costs. There is no need to invest in server capacity and software licenses. Simply adjust the subscription.
  4.      The provider is responsible for upgrades, uptime and security -“SaaS solutions typically offer seamless, automatic, frequent upgrades as part of the ongoing subscription charge. Because these upgrades happen more frequently and incrementally than on-premises solutions, they typically have significantly reduced testing and end user acceptance and training costs.” [2]
  5.      Higher adoption rates – Because the software is accessible via familiar web browsers, SaaS apps tend to have lower learning curves and tend to present a more intuitive end user experience.
  6.      Designs that facilitate integration and scalability – Most solutions are designed to support some amount of customization. In addition, they typically include comprehensive APIs to allow connections not only to internal applications like ERPs or CRMs but also to other SaaS providers.
  7.      The ability to work anywhere – Since the software is hosted in the cloud and accessible over the internet, users can access it anywhere they can get connected. The better SaaS providers will ensure that their solution is device, operating system, and/or browser agnostic, too.

Therefore, no matter at which level a solution exists in the model outlined herein, it is essential to consider whether it is a SaaS solution or not.  It may even be prudent to opt for a SaaS or cloud-based solution that is at a lower level in the model presented below, if one at a higher level can only be deployed on-premise.

Level One: Find and Leverage a Core Enterprise Information System

Enterprise Information Systems (EIS) exist for every major industry.  EIS’s are also known as enterprise resource planning (ERP), core, or enterprise application (EA) systems. Identifying the one that matches the majority of our business needs is crucial.  Finding a system that is just the right mix of the following characteristics is the key:


Advertisement

leving

  1.      The EIS should be an “ecosystem” – a platform that facilitates accommodating many of our existing and desired future business processing needs.
  2.      The EIS should offer a suite of features that can be implemented in a modular fashion.
  3.      The EIS should be built on solid technological foundation for proven reliability, security and regulatory compliance.
  4.      However, the EIS provider should also be a forward-thinking company, willing to invest heavily in R&D to realize continual improvement for their EIS.
  5.      The provider of the EIS itself should have a solid track record of delivering quality information systems and maintaining meaningful customer relationships.

The right EIS will go a long way in satisfying an organization’s business processing needs.  However, every EIS has its limits.

Level Two: Find Solutions from Key Collaborative Partners to Fill Some Gaps

Quality leading industry solution providers will not only have an EIS solution to accommodate many of the business processing needs of that industry, but they will have formed key, collaborative relationships with partner IT solution companies to help them deliver an even broader suite of solutions to their customers.

These partner-provided systems will be the next source for satisfying additional processing needs.  The best systems will come from collaborative partners

  1.      whose software solution seamlessly integrates with our EIS;
  2.      whose software development teams work hand-in-hand with the EIS provider, keeping all facets of their systems in tune with the evolution of the related EIS;
  3.      whose systems themselves may be modular or capable of enabling features on an as-needed basis; and
  4.      who also place a high value on customer relationships to keep in tune with the business needs and wants for which their software should provide.

Level Three:  Find Other Niche Solutions with Compatible Interface Technologies

An EIS vendor can only see so much of the business needs landscape that surrounds the industry for which their EIS is a solution.  They will usually partner with other vendors whose solutions fit well within a broad spectrum of their customer base.

So when a line of business needs a technology solution that neither our EIS vendor nor any of its partners can provide, there are usually other vendors we can turn to.  Fortunately, many of these solution providers have developed systems with a modern and mature application programming interface (API) and an associated data transport mechanism like an API gateway, messaging bus, Electronic Data Interchange (EDI), or an eXtensible Markup Language (XML) transport protocol such as Simple Object Access Protocol (SOAP) or REpresentational State Transfer (REST).

Level Four:  Find Other Niche Solutions that Allow for ETL-Type Synchronization

If no solutions for the niche need have a mature API, then we should next turn to vendor-provided applications that deliver the necessary requirements and desired features, and can handle some type of mass-updating or bulk-loading of data into and out of their system.  This kind of integration is commonly known as an Extract-Transform-and-Load (ETL) method of synchronizing two disparate systems.

There are very few systems that handle an island of data that has no relation to any other system within the bank.  This means that where the data in a niche system overlaps with other existing systems, by necessity we will have a double data entry condition.  This should be avoided at all cost!

Level Five: Develop IT Solutions In-house

leving 2

Inevitably, we will come across business processes that are unique to the way we want to provide our services.  If a thorough market search – including reaching out to peers in our lines of businesses to see how they may accommodate similar business-delivery desires – renders no existing technology solutions for these “uniques,” then two questions must still be asked:

  1.      Does this unique way of delivering our business offer measurable value or align with our most identifying business strategies (which can sometimes be intangible)?
  2.      If the answer to 1 is a resounding “Yes!”, then do we have the necessary, not-already-fully-utilized, technology staff to design, develop, deploy, and maintain a solution to this need?

Only when both questions are answered affirmatively can we proceed at this Level.  And even then, with caution!

Limiting the Emotional or Subjective Approach

A business analysts, our goal is to try to be as objective as possible when suggesting or providing technology solutions to our employers or clients.  Our sponsors or stakeholders often, however, come into system selection initiative all fired up about System XYZ that a peer has told them about or that they saw demonstrated in some venue – and they just have to have it!  Taking a structured approach like the one discussed above is always a best practice.  We want the best solution, the one that will help move the organization forward to even greater success.

References

[1] “Why SaaS? 7 Benefits of Cloud vs. On-Premise Software,” Mandy Movahhed, June 18, 2014, https://www.handshake.com/blog/why-saas-cloud-benefits-vs-on-premise-software/

[2] “The ROI of Software-As-A-Service,” Liz Herbert and Jon Erickson, July 13, 2009, http://resources.idgenterprise.com/original/AST-0113124_forrester_roi_of_saas_1_.pdf