Home
407-909-0930
skip to the main content area of this page
Bayside Incubator Blog
Sharing Ideas on Collaboration and Innovation

Bayside Technology, LLC

Technology solutions to help your business succeed.

Phone:
407-909-0930

Email:
info@baysidetech.com

Choosing a Business Intelligence (BI) Tool

April 26, 2010 @ 1:31 pm
by Bob Lautenbach
Filed under: BI Tags:

BI has been around for a long time, but only in the past five or so years has it really taken off, both in the buzzword department and as a real solution to business problems. If done right, BI empowers members of your organization (and your clients if needed), by providing them tools to report against and analyze real-time or semi-real-time data.

In the old days, reporting was a tedious process, and from the business perspective, appeared to take forever.  Here’s a likely scenario:  you think of a report you need, you write-up your report request, send it to the IT dungeon, and in 2-3 weeks you are informed it is available from menu “X” in system “Y”. You get excited, login, only to find the layout wrong or groupings off. You start the request process all over again (fun times!).

With a BI tool at your users fingertips, they can sort, group, heatmap, piechart, export, and print to their hearts content. Never having to request another report from IT again (well, almost never). BI tools increase productivity and add efficiencies to an organization. There is one caveat. You organization must be ready for BI. If your user base is not able (through lack of training) or not willing (fears change, afraid of technology or are just plain lazy) to use your shiny new BI solution, your investment was wasted. Be sure to get your people on-board and excited about BI and what it can mean for them before you make a purchase.

I recently implemented a BI solution for mid-sized client and thought I would share some of the things I think should be included in every BI offering. Most of the items I will mention are provided by the major vendors such as;

The list below outlines items I feel are critical in a BI package.  It is by no means all-inclusive.

A BI tool should:

  • Offer various Charting/Heatmap options
  • Provide the ability to sort, group and parameterize reports (some vendors do not support the HAVING clause from within the report designer. In that case, you will need to implement HAVING statements at the database level)
  • Provide the ability to schedule reports (and auto-email/deliver..in various formats)
  • Offer logging of user access to the system (an audit trail)
  • Provide the ability to hide data objects from select users, but still allow them to run reports on those data sources (via permissions)
  • Provide the ability to share reports with other users
  • Provide the ability to filter data by user group to limit access to data (by client, region, etc.). When a user logs in, you may want to restrict them to certain data, a single client for instance. The BI tool should be able to handle that level of restriction.
  • Offer multiple options for login security such as, single-sign-on, windows authentication as well as traditional forms authentication. (most vendors offer single-sign-on capability but be sure to look closely at their specific implementation to ensure it meets your security requirements)
  • Provide the ability to export reports to various formats
  • Provide the ability to add calculated columns and aggregate summaries
  • Allow you to name you database columns anything you like (sounds strange, but we encountered a parser that did not like the words UPDATE or DELETE in any part of a field name..i.e.: last_updated_by)
  • Allow users to use a field as a parameter, but restrict users from displaying the field on a report. For example, I should be able to query by SSN, but I would rather my users never display a full SSN on report. In that instance, I would offer a masked SSN field for display.
  • Allow the System Admin user that typically comes with a BI Tool to actually have full Admin rights across the entire application. This again might sound strange, but I recently used a product that provided a system admin but certain permissions where denied to the admin as you moved throughout the system. The workaround was creating group admins for each user group in the system. Very tedious and not intuitive.
  • Provide a metadata layer where you can add user friendly field names, descriptions and even formating information per data object.
  • Provide the ability to create relationships between objects (in case its not already done at the database layer)
  • Provide the ability to auto-hide unrelated data objects. Essentially, if you select a data object (object “X”) for a report and no relationships to other data objects have been defined, then after you select object “X”, all other available data objects auto-hide from view (making them unavailable for that specific report). This is a great feature especially in less sophisticated organizations, as it helps avoid producing run-away queries.

Most, not all, of the BI offerings I mentioned at the beginning of this post have the features I listed above (some more quirky than others). Each organizations needs are unique, so in the end you will need to marry features to your specific requirements. However, I have found that the items above are core to most business needs.  Take your time and test-drive each product on your potential buy list.  You will be glad you did.  Happy BI Hunting.

Heads down collaboration

April 6, 2010 @ 3:03 pm
by Dave Konopka
Filed under: team work

Collaboration is an important part of team work. It’s also important though to strike a balance between team work and productivity. After all, it’s hard to make much progress on a project if your team is wrapped up in meetings 90% of the time.

One way to strike that balance is to encourage team members to communicate on their own schedule. In person visits, phone calls, and instant messaging are great tools. But they require immediate attention and can derail a person’s attention. An alternative is to use disconnected communication tools.

Provide an internal blog, a short message Twitter clone site, or an IRC style chat room and give accounts to everyone. Whenever someone hits a wall or completes a task, they can post a short message. The running list of messages will be available whenever other team members check in on it. Everyone keeps up with what’s going on without the pain of time draining meetings. You also get the added benefit of connecting folks who work in disconnected offices.

Some disconnected communication options:

Meetings don’t have to be time draining. Short, focused meetings can be very useful. Just make sure every meeting has a clearly defined purpose. Get in the habit of sending out agenda points. Keep the agenda points limited to decisions points or group related updates.

Encourage team members to discuss and refine the points ahead of time using your collaboration tools. Don’t schedule an hour unless you really need it. More often than not 15 – 30 minutes gets the job done.

Whenever your team is gathered you’re spending as many worker hours as there are team members. Hash out as much as possible upfront to make sure the time spent together is worth the cost.

How to Run a Meeting Like Google
You don’t have to adopt all of the points immediately. But one or two might help increase your team’s productivity.

What other forms of communication do you find work well for you? Leave us some ideas in the comments.

Spec’ing the specs: Rethink the manual

April 1, 2010 @ 6:38 pm
by Dave Konopka
Filed under: software process

In the first post of this series, Spec’ing the specs: What should my software do?, we took a look at some of the high level considerations that go into planning software projects. In this post we’ll focus in on the online tools and processes that teams can use to capture project requirements.

Why do we need to document requirements at all? There’s no shortage of horror stories out there about the pitfalls of over documentation. You’ve probably seen a phonebook-sized spec document propping open an office door somewhere.

Documentation for the sake of documentation is a waste of time. But clear, concise documentation supports software projects in a few key ways:

  • Clearly defined requirements guide your team’s decisions throughout the life of a software project
  • Consistently recorded decisions remind your team why you made the choices you did weeks, months, and years from now
  • Consciously deciding what your software should do makes it much easier to test that it actually does it once it’s complete

(more…)