In the past I have seen two incidences when a firm decided to migrate the PCLaw database to SQL. Both related to the same firm, with the first being for one branch and the second for the other. Different databases for different offices; different reasons to migrate to SQL; and all for the same firm.
The reason for the first office was to enable better data mining, extraction of reports for business intelligence, ensure data integrity and minimize data corruption issues. The upgrade was a disaster, crippling the Accounts office and within two days the database was reverted back to C-TREE. All happy going from then on.
The database at the second office was faced with a forced upgrade situation imposed upon by the consultants who were engaged in implementing a DMS (Interwoven Worksite). Without upgrade of PCLaw to SQL they were not going to touch anything. And that was after the firm had signed off the purchase (of Worksite)! In a nutshell there was a complete disregard of the Accounting system for the sake of PCLaw integration with Worksite. Despite the risks presented in a “crystal ball” fashion and despite earlier warnings, the firm upgraded to SQL.
Fast forward two years later: The Accounts office on the C-TREE database continued with greater speed and efficiency whilst the other office on SQL began getting issues that got from bad to worse. To put things into perspective the branch on C-TREE database was consistent in finalizing its year end accounts & audit by February while the other office had the worst year as it took 9-10 months in finalizing its Audit/Accounts.
So, what went wrong? The cause is “Interwoven” – yes as the DMS name suggests all issues interweaved from slowness in report generation, data corruption, errors prone balances which the Accounts team relied, to finalizing periodic and Year-End accounts and audit. The domino effect had disastrous consequences.
A short horror story and simply because unlike more mature programs (Worksite in this case) PCLaw was not designed to operate on SQL. So, should a firm upgrade to SQL or stick to C-TREE? That is probably a topic for next discussion.
No comments:
Post a Comment