Thursday, 26 February 2015
For its foundation stones, CRM requires some basic building blocks in terms of storing data.
As with any technical solution, using CRM successfully depends on storing data in the right place and in the right way, which can only happen with careful consideration and planning; mapping your data into a sensible structure that the CRM can support.
That means planning for the general rule and carefully corralling the exceptions; just because you can go wild with custom fields for any and every occasion, doesn't mean you should.
Wednesday, 25 February 2015
The user requirements are in; the specification and designs signed off; development ready to begin; then you realise you have no idea what the implementation looks like!
With a major programme such as CRM to run, a phased implementation plan, scheduling delivery of slices of functionality, over the life of the project, would be a good approach. We're aiming to get the foundation components in place - the database schema, frameworks, server infrastructure, then, while detailed design and development continues, identify some quick wins to provide business benefit early on.
There's no point waiting for a monolithic development to complete if everyone has retired or died in the interim...
Thursday, 19 February 2015
(Pirates of the Caribbean)
This is not the only way, nor is it drawn from any particular method; this is just a convenient set of hooks on which to hang our data design meeting this week. You could apply it to any kind of design review, and it works well in the context of much more formal methods.
So my agenda for tomorrow looks like this:
Wednesday, 18 February 2015
...or more precisely, when a reputable website such as Wordpress.com displays a warning triangle and the message: "this site does not supply identity information."
You may notice the warning triangle in the address bar on sites which use the HTTPS, SSL and TLS protocol and certificates, and get the message when you scroll over it. Wordpress? Really?
Let's replay Internet Security-101, with apologies to the technically 'ept' (not the 'inept').
Command and Conquer: Introduction to Git by Lucas Westerman originally appeared in Full Circle Magazine Issue 84
I received an email from a reader of Command & Conquer, asking me to write an article on using Git – specifically things such as what a fork is, what pulling is, and what exactly a commit is. He also followed it up asking about auto-merge errors and how to fix them. I will do my best to cover each of these points in particular.
However, as most of my experiences with Git are via Github, which offers some extra functionality on their website that isn't the “vanilla” Git experience, there may be some aspects of my explanations that do not apply to a custom git server.
Thursday, 12 February 2015
Firefox on the work desktop was not playing nice; realising it looked funny, I did a version check and discovered it was stuck on 24.0 ESR.
Normally Firefox updates automatically. To kick off the update process, go to Tools, About and the version checker usually appears below the version number.
As Mozilla has a number of update channels, each with differing frequency of software releases, ESR seemed like a poor choice given I hadn't updated in six months. Working as I do on the web, that's equivalent to 4.2 years.
Tuesday, 10 February 2015
Received wisdom over the last twenty years has concluded from a time/cost/quality perspective, if you need to deploy new software, you should buy not build. This is especially true of a big, complex item such as a CRM system.
In many vertical market applications, full-featured packages offer quick start-up with known costs, be it from an original vendor, a reseller, or via the Open Source route.
But while commercial packages may offer a standard approach to implementation, these proprietary systems, will most likely demand you use the software house that designed and wrote it, or their approved resellers (consultants) to help you implement it. So what options are there?