Please enable JavaScript.
Coggle requires JavaScript to display documents.
Evaluation of needs for company secretarial software - Coggle Diagram
Evaluation of needs for company secretarial software
As with any major purchase, a significant software or application system should not be chosen lighly and it is important to assess in advance exactly what the objective is
The first stage is to understand what the current system delivers, the areas of weakness and the wish list the users of end recipients of the system output would like to see
The process of esbtlaishing the businesses requirements if often poorly combined with establishing standard operating procedures and practices, both elements are important but all too often the desire to adopt standard processes obscures the underlying business requirements and can lead to poor choices being made further along in the process
The business requirements should be a framework from which the standardised procedures and practices are based rather than the goal itself
These business requirements should be documented in a structured and methodical way with prioritisation of current and future needs and differentiation between needs and wants are important areas to focus on
Application sellers can also use this documentation to match their functionality against, highlight any areas where any bespoke needs might be acquired and introduce additional complimentary processes within their product of which the end users might not be aware
There are many different ways of identifying and documenting business requirements including
Focus groups within the compnay
A group of users that perform specific duties and tasks that can be polled to ascertain their duties, functions and system interactions within the company
Interviews
An account of what is currently being done to support the business
Interface analysis
An examination as to inputs, outputs and intermediary steps that may be required for the system to function and define interoperability to existing systems
Surveys
An internal account from different points of view as to how operations and processes actually happen
Observation
This refers to walking around and drawing your own conclusions as to how things are done
The business requirements document should include all processes that are or might be carried out whether that is daily, weekly, quarterly or on an ad hoc basis
Documenting the current processes should be relatively straightforward however the business requirements should also look forward and try and capture new functions that might be required in the future or additional processes that the new software solutions will facilitate
To avoid unnecessary confusion, it is important to ensure that those tasked with documenting the processes especially those involved at the periphery understand the purpose of the exercise as otherwise critical processes right be omitted in error or additional features not requested at an early stage
Omissions can cause delay and increased costs and at worst can cause a new software solution to represent a backward step in terms of a departments operational efficiency, effectiveness or capability
In addition to ensuring that all current processes however rarely occurring are captured it is also important to distinguish between a need rather than a want, needs are key to ensuring the platform is able to provide the full range of current activities and must have priority over wants
The process of documenting the business requirements and existing, potential or actual business needs and wants is susceptible to scope or requirement creep
Once your business requirements document is finalised the next stage is the creation of a tender document which potential vendors iwll use to demonstrate how their solution/platofrm matches the required business process and identifies any confirmation or additional development work that must be required