As Qrimp approaches 400 installations, it feels great to see how many businesses and people we are helping. At the same time, there's still a lot of pain out there in a world where people are buying the wrong software.
I just read an article at Computer World UK called, "Why ERP is still so hard." It's painful, here are some quotes from the article.
Of course, ERP applications can change. But it'll cost you. In customizations. In change and process management. In upgrades. A typical company, notes the CFO study, will spend an average of $1.2 million each year to maintain, modify and update its ERP system.
That's after spending $3 Million to $17 Million to implement it in the first place.
Oracle, for instance, will heavily discount license pricing upfront but will, rest assured, make that up on the backend - from its 22 percent maintenance and support fees, on which it does not negotiate.
I wonder how software companies get away with this. I knew when I started my business, I wouldn't tolerate it. Why should I let some software company bully me like that when I can build it myself?
So before I got started on my next venture, I started on the software. I'm a software engineer, it's what I do. I saw the benefit that software brings to organizations. I would walk around companies I worked for and consulted for and see the software I wrote on countless desktops and it feels good. I want employees of my own company to feel good too and I want them to use good software.
So I ask myself, "Why is ERP so hard?"
I think it's hard because technology is hard. People don't know what they are buying. I talk to lots of small businesses and I see them buying bad software, simply because they can't tell the difference between good software and bad software. We are in a market for lemons.
Never say Never
The article continues the discussion of hard software.
CIOs, too, can play a starring role in limiting costly customizations, by educating and imploring business managers and users why customisation, in the long run, is often not the better route. But that task is never easy.
I wouldn't say that is true. I think every business is different and every business needs different software. If you don't customize the software, you have to customize the people. You have to change your entire business to suit the software, when it should be the other way around. Adapt the software to the business. Retraining your people to a new business process, takes time. It's a big distraction. Even simple things like changing the names of things can make a big difference.
One of my acquaintances was working for a company about to roll out a popular CRM system and she told me, "I don't have time to learn it. I'm too busy -- we're all too busy. We have to change the way we do everything to use this new software, it's easier to keep it in Excel." I cringed when I heard that. A lot of software decisions like this are made from the top down, just like software is built. In cases like these, slick sales men and women convince the management to buy the software and employees resent it. They know the project is doomed to failure, but no one listens. They think it's easier to adapt their business to the software than to adapt the software to the business. That was true in the past, but not anymore.
The problem with ERP software is that the underlying infrastructure, the code that runs it, is so hard to write. It takes years to write the code to manage an accounting process and then the ERP companies take that same code and sell it to all their customers. If they want to customize the functionality, they have to rewrite the code, which takes months or even longer. Some ERP roll-outs take years.
Qrimp is different
With Qrimp, we build software that runs entire business in just a matter of months -- from scratch. We build the software to match your business processes and your people. It doesn't take years to write software anymore, it takes a couple hours. It sounds too good to be true. It's unbelievable, but what I can't believe anymore is that people are still building software systems the hard way. It's software, why is it so hard?
You can't customize traditional ERP, because upgrades break it
One of the best features of Qrimp is that upgrades don't break your software. The first enterprise system, built on Qrimp almost 3 years ago has been upgraded multiple times and it still works flawlessly. No data has been lost, no additional maintenance time has been spent unbreaking the system -- Qrimp just works.
Traditional ERP breaks, because it was written top down. The ERP company sees a problem like accounting, HR or supply chain and they write a bunch of code to solve the individual problems. Then they piece all together after the fact. But that's the wrong approach.
Qrimp was written from the bottom up
Qrimp is a platform. We spent the first years of R&D building a flexible platform, exactly so that it can be customized. I knew when I architected the system that it was going to have to be agile to support the changing business requirements of a growing company. This is where traditional ERP fails. The ComputerWorldUK article says a lack of flexibility is why many ERP packages fail:
"Companies grow and change, acquiring new business lines and divesting themselves of others. They open new facilities or consolidate operations, add partners or outsource functions, centralise or decentralise the back office. Reporting requirements increase as regulatory bodies heighten oversight and as companies expand across borders.... In short, businesses change, and as they do, so do management's information needs."
Traditional ERP fails, because it can't change. Qrimp was designed to change. That was the #1 priority when building the system -- enable changes to the software.
Hard software stifles business
Business changes and adapts. You don't want our software to be a ball and chain, you want it to be flexible and move with you. Even adding a new menu or changing a column, or adding a column with traditional ERP can take weeks or months. It has to be rolled out and tested and integrated and recompiled and all sorts of other things that most users of the system don't know about or care about and really, why should they? They need to do their jobs and they need to be able to store and track the information effectively.
I love Qrimp, because it grows with us. As we start new ventures, build new websites, attract new customers, implement new features, Qrimp just keeps rolling right along.
If you'd like to learn more about how Qrimp can enable your business to grow, build more revenue, adapt to change and be more agile, please Contact Us! We want to help.
I was recently building an application to help me with a home remodeling project. I built one table, a todo list, with a tree view that had a Materials table related to it. The materials were items that I'd need to complete the task, such as paint, plywood, sand paper, etc.
So in my treeview, I had a list of tasks like this:
I wanted to see how much each level of the tree was going to cost to complete so I could make better decisions about where to start on my home remodelling project and where I would get the best bang for my buck. Each Qrimp app comes with a gettree operation which will return a table with a nicely organized structure showing how items relate to each other in a hierarchical manner, so I adapted it to calculate the sum of the estimated cost for the materials. I then added a share data to my detail view for a particular todo list item.
Then I realized that this information would be good on the tree view as well, so I added a feature to Qrimp that would allow me to run a query for each node, passing in the ID of the item to that query.
To access this feature, add &qid=QUERYNAME to your URL.
My document.referrer says you are coming from HN, so I thought I'd preface this post especially for you.
A lot of stuff I've read at HN prompted me to finally write this. I saw the Why JavaScript Web Analytics... post today. I've also seen lots of comments from people wondering what other HNers are hacking on. This analytics tool is something I'm hacking on and so is Qrimp -- it's my baby.
Just briefly, Qrimp is a browser based development platform. It's usually $50/mo, but I would love to get more opinions from real hackers, so if you'd like to learn more about Qrimp or just give us some feedback, sign up and add your HN user name in the "How you heard about us" block and I'll create a free account for you.
Why analytics are important
If you want to better understand your website visitors, your customers, or your potential partners, you need to know what they know about you. You know what they know, partly through examining what they are reading at your site. Which types of articles get the most attention? Which products are the most popular? Which pages are your potential customers looking at that convinces them to sign up?
It's really about data and information and turning those into Knowledge you can use to improve your company -- or yourself. Sometimes you don't know how you are going to use additional knowledge, but I know that the more I know, the better able I am to react and that's why site logs are important. If your site starts to perform slowly or you get a lot of traffic and you don't know where it's coming from, your ignorance is hurting you in ways you may not even know.
Why One-size-fits-all doesn't work
You may be wondering, "Why waste your time building your own analytics when there are lots of options out there?" Well, the simple answer is that with Qrimp it really doesn't take that long. There was information I wanted access to, that I couldn't get out of Urchin or Google Analytics. Some of these packages are good, but when I used them, I always felt constrained. I felt like I wanted more and I knew there was more knowledge to be gained from the logs than I was getting.
For example, Google Analytics really limited my ability to drill into details about each visitor. If someone signs up for Qrimp, I wanted to know where they came from, what they looked at. Are they coming from a university? Really, there are a lot of questions I had that were left unanswered by the statistics packages out there designed for all websites. I wanted a statistics package designed for my website.
When someone signs up, I log the IP address for the computer they are using. Since the sign up system is also built in Qrimp, I knew I'd be able to create a link from that IP address directly to the analytics system and immediately know everything that customer looked at before and after signing up. This kind of knowledge would help me understand better what is in the mind of that particular customer.
Problems javascript based solutions
Google Analytics is also JavaScript based and I found the statistics produced by GA was really quite different from Urchin stats generated from the raw logs. The discrepancy made me uneasy. I knew to get the best information, I had to go to the raw logs.
One of the biggest issues with Urchin was that the navigation just didn't feel right. For example, in the chart below, I wanted to click on the bar and examine the sessions, but urchin doesn't let me do that. That kind of functionality is built into Qrimp, so I knew it would be very easy to present the data more intuitively.
Also, the urchin statistics are presented on a site by site basis, but because Qrimp is a multi-tenant system, I wanted to be able break down statistics by Qrimp instance. Were visitors coming to www.qrimp.com also visiting The Developer Network? Did they start out at the Cloud Computing Portal or maybe they were techies looking at the Tech Jobs Charts? Using Urchin, answering that question would be almost impossible.
Another issue was with website referrals, here's an image: See how some of the information is disregarded? If you read Hacker News, you'll know from that link, there's no way for me to see the comments about whatever link it was that was submitted to Hacker News. That information is just lost. But when someone refers to a page at Qrimp, I want to be able to go to that page and see what they are saying.
File based analytics can't be queried
Most analytics programs aren't database driven. They look at your logs and then build a bunch of reports or static files that then present your data to you in ways they think you'll want to see it. But without a comprehensive querying system, they limit the visibility of the data and that's really what I was after and that's what Qrimp is all about.
What I wanted to see
Whenever I would use one of the standard analytics packages, I'd always have a lot of questions. I've been using website analytics tools for over 10 years now -- way back when I had to examine logs manually. I first tried awstats back in the day, which I loved, and then Microsoft had this great tool called Site Server which had some built in analytics processing. Site Server's analytics was really nice, but it "went away..."
On a side note, that's part of why I built Qrimp -- I was tired of my favorite software going away. I knew if I wanted software done right, I was going to have to do it, but there's so much software that I wanted to build, that I decided to start on the platform. It's my mission to make sure Qrimp never goes away.
I wanted Individual Visitor Logs
Individual visitor logs was something I really wanted to see. Not only for a single site, but across all sites. Was someone using their Qrimp app, then clicking on the Help link and finding more information from the Developer network? Which help topics were they reading and when? I need to know so I can make Qrimp better.
New Domains
I also wanted detailed reports about which new domains were coming to the site. Lots of smaller companies come to check out Qrimp and maybe they'd like to buy it. These new domains are hot leads I can examine, build up a case, and then call that company and ask them if they'd like to talk or see a web demo.
I've also been working with different universities who want to get their students up and running on Qrimp. I love the idea and so I wanted to see which new .edu domains were coming to Qrimp and then perhaps I could email the Computer Science department and see if they were interested.
What I did NOT want to see: Log Spam and Robots
I found that as I continued to use the Urchin statistics, I was getting more and more refers to websites peddling drugs, porn, and myriad other types of spam. There was no way for me to get these hits out of my logs unless I filtered them out myself.
I also didn't want to see a lot of details about the Robots. I developed a few algorithms to figure out what a robot was and then flag and remove those hits from the big list. This allowed me to really filter out the logs and drill into only the human beings. I might have a couple hundred sessions one day and then find out that that half of those are robots. It's bad data and I don't care about the robots -- I care about customers.
Customizing Qrimp
So I had to get the raw logs into Qrimp. In the raw logs, these statistics are presented with one request on each line. I needed each request to be a record in the database, so I had to write a little bit of customized code.
Downloading the Raw Logs
I run Qrimp on a local instance, so all I had to do was create a new database and install it. The hosting provider makes the logs available through FTP in ZIP files, so I wrote a script I run once a day to attach to the FTP server via sFTP and download any new log files. I use WinSCP which has an awesome scripting language that I use to automate it. I create a scheduled task or "cron" job to run this script each morning.
Parsing the logs
Then, I wrote a little code that would unzip the raw logs, open the text file contained within it and go line by line extracting out the logdate, servername, referer and other details about a request. I added a little bit of security to it so that the database wouldn't get corrupted by script tags via cross site scripting and that sort of thing. I've parsed lots of files like this, so it didn't take long, maybe an hour or two.
I thought having detailed analytics like this would be interesting for our customers as well, so I built the rest of the import process into web pages. At some point in the future, I may automate this process too or make it a commercial add on, but for now, it's part of my daily routine.
The first thing I do is click on the Qrimp server I want to import logs for from something like this:
When I click on one of the servers, I usually pogo-stick them, I scroll to the daily import and click it:
Then I see a simple page with a progress bar letting me know how long it'll take.
Back into the Browser based development
Everything beyond this point was created using only the Qrimp development platform. Once the data was in the system, custom queries, field templates, portals and everything else was super easy.
After importing all the new logs, I reindex the logs table so queries are fast. Then I do a reverse DNS lookup on the IP addresses so I know a little bit more about each visitor. Qrimp has a reverse dns function built in, so I created an external data source to extract this information. I know this isn't the most efficient way to do these, but it looks cool and it's fun to watch. Here's a video of that, it's neat to watch. You'll notice in the video that I use Opera to reload the page automically every 5 seconds.
When it's complete, run one more query that examines the logs, looks for robots, spammers, and does a bit of denormalization and truncation of old entries to keep the system running fast. This is running on my laptop and I only have 2GB of ram.
In the future, I plan on storing aggregate information for the older logs, but for now this is fine. I keep the log zip files, so it'll be easy to keep all the data on a larger server or in aggregate in the future.
Screen shots
So now that I have my data in the Qrimp database and processed, I can examine it. I have a portal page, here are my settings for that:
One of the charts on the reports is requests by day for the past month (click for full size):
Another report is "Popular pages at Qrimp," which shows me a page like this (click for full size):
I like the calendar view too. I created a custom template that allows me to see sessions, bandwidth, and unique referers by day. I can click on the links to drill in.
If I click on Sessions in the link above, I see the image below. I can click on the numbers under Sessions and Referers and get more details about the numbers behind them.
Also, notice the icons are linked to the server names in this chart too. It's just a field template in Qrimp, so anywhere there is a servername column in a grid report, I can quickly get details for the server I don't have to customize every single report.
If I click on the number under referers, I'll see a list of sites sending traffic there.
Notice in the image above, there's the word "spam" by the link to the referer. If I click it, it takes me to a form where I can add it to the list of spammers and all of those referers will be excluded from future reports. The Spam referer link is pre-populated into the form so all I do is click TAB TAB Space (to click the create button) and I've added the spammer. I set up the workflow so that as soon as I add the spammer, I go right back to the report where I found it.
Integrating with other sites
Now the really cool part starts. Because I'm using Qrimp for all our data systems, anywhere we have an IP address, I can create a Field Template for that item that will link it to our website analytics program. For example, when someone signs up for Qrimp, their IP address is logged. I added a little icon that when clicked, shows me exactly what that user viewed before signing up. This will help me improve my site so that we get more customers in the future, here's what that looks like:
Integrating the sites like this is very simple, here's the HTML behind the field template for the IP Address data:
Another cool part is that our website analytics application is running behind our firewall, but because Qrimp links can go deep into data, we can structure the querystring to link directly to particular pieces of information, even if the systems aren't running on the same server.
Conclusion
All told, I've spend probably 10 to 20 hours on this website analytics system. There is a lot to the system I haven't shown you, but the amount of power I can get out of Qrimp is really amazing for the amount of work put into it. The amount of time I lose learning how to use Urchin or Google Analytics, or even just maintaining the JavaScript links to GA is probably more than that over the life of the application.
But now I have unlimited access to my data. I can query it any way I like, I can integrate it very easily with my other systems.
I love Qrimp so much I almost about to cry right now! It's so powerful I can barely contain myself.
So I drew out some of the items from the Situational Application Brainstorm for the Customer Extranet. Here's the white board drawing for it. Click for the high res version:
What I've done is list some of the things from the brainstorm in blue above the properties for those items. The red arrows are drawn toward properties that are actually other things. For example, when creating a new Project, that project will be assigned to, or created under, a particular Customer.
To get started creating the Customer Extranet, I go to the Create Tables menu in my fresh Qrimp app:
I'm going to start creating my tables in order of hierarchy. What I mean by that is that I want to create tables that have no pick lists first. For example, the customer table doesn't depend on any other tables, but projects does, so in order to add a pick from customers from the projects table to the customers table, the customers table needs to exist. If I create the Projects table first, then I'll need to add the pick from to the customers table after the fact, which will be an additional step. It's okay if you create some out of order, but I like to do it this way.
Customer Table
In the image above, you can see how I've selected to create my customer table. I've added a contact email and phone number, where in the white board diagram above, I only had one property for contact.
When I click the create table button I'm taken straight to the Add Customer form and can begin populating customers into my database. I'm not ready to do this yet, so I'll continue creating the other tables needed for my customer extranet.
Project Table
Here in the project table, I've decided to add a description field that will represent the requirements. We should focus on keeping the application simple and because most people understand what a description is, more than a brainstorm, I'll use the name description.
When I create the table, Qrimp adds this form to my app automatically, just like for the customers table.
Iterations Table
As I've begun building this system out, I've realized that Iterations should have a project field. You won't see it on the white board drawing, but I'll add it here when I create the Iterations table.
Tasks Table
I've also thought more about the concepts of Problems, Work Items, Bugs, Issues, and realized all of these are really Tasks. All of these things are talking about work that needs to be done. If there is a bug, the bug needs to be fixed. Problems need to be resolved, issues, need to be clarified or resolved as well. All of these things are related to an Iteration, so I will create my Tasks table with a pickfrom iterations. This will make it easy to create new tasks and assign them to iterations in the past or future and figure out what to do with them as they are created.
I've combined many of the properties of WorkItems and Problems into this table and given it a TaskType field. This field is a single line text field, I'm not sure how many different types of tasks there may be in the future, but I can easily convert this field to a pick from once I've entered some Tasks.
Invoices Table
Payments Table
Line Item Table
Next Steps
That's all for this installment of the series. Now that our application is created, we can start adding information to each of the tables. There are still some steps to modify security.
In further installments, I'll configure security so that we can create new customers for our Extranet and allow them to log in and see their projects and invoices. We'll also want to allow them to add issues to the project so we can keep track of any new items. We can add those ourselves as well. We'll probably also want to be able to quickly add a line item to our invoices directly from a task so that the customers can see how much things cost and why they are being billed.
The important part of information mangement is actually creating the system to input the data and keep track of it. Qrimp makes it easy to do this and also modify the application moving forward. It's very agile. We can continue enhancing and modifying the application to do virtually anything a web app can do using standard web technologies all from the browser.
As I use the customer extranet with our existing customers, I'll find things I want to add and ways to make the app easier to use. I'll use this example to show you some tips and tricks in the future.
Here I want to pause with our Customer Extranet and build some background. This is the kind of thing computer engineers learn on the job. Some university programs have courses on it. If you don't know what data modeling is, your brain is about to explode. You might want to read this article about How To Learn About Everything. It's normal to be confused at first.
Let's start with some videos. Youtube EDU has some lectures by professional educators. You may want to watch these at home or on the weekend... a few times.
If what you are hearing is "over your head," don't get discouraged, thousands of people do this kind of abstraction every day around the world and there's nothing about those people that you don't have. You will need patience and courage to get through it, just like developing any skill. It's worth it, it's a skill you'll have forever. It will change your life.
There is a reason database architects earn $97,000 a year. Do you want to pay that database architect $97,000 a year or do you want to learn how to do what that Database Architect can do? It takes practice and energy, but you can do it. I never took a database modelling course at university, I learned it all on the job. I made a lot of mistakes, but now I could model your entire life with Qrimp. It is possible.
Data modelling reading and community
I'll start with the Wikipedia Article about Data Modeling. There is a lot of information there and it is edited by professionals. Don't get discouraged if you don't understand it.
If you'd like to read more about data modeling, see some examples, and join a community, the best resource I have found is run by a very, very nice gentleman from the UK named Barry Williams. Barry started out with his own website called Database Answers. He has a huge library of example data models and he runs a The Database Answers Social Network at Ning. Be conscious of his time. Lots of college kids go in there and ask him to do their homework. Use the forums to ask for comments on your data model, don't ask them to do your data model. He may already have a data model you want in his library of data models (there are hundreds in there). Some of those data models alone could cost you thousands of dollars if you paid a database architect to build one for you. Amazing isn't it?
Data modelling is hard
One of the most difficult parts of building information systems, whether they are situational applications or regular applications is determining how to represent your real world scenario with a description the computer can understand. The concepts we have in our minds are complex and convoluted, but the computer doesn't understand when you describe something with all sorts of words like we did in our situational application brainstorm.
In this series of posts, I have simplified a lot of the concepts. I use People, Processes, and Things. Experienced data modelers use more advanced terminology like Unified Modelling Language (UML). In UML, the words are different than the words I'm using. Instead of People, they call them Actors, instead of Processes, they call them Use Cases and instead of Things, they call them classes. UML is much older than these blog posts and much more detailed.
Data Modelling is about Abstraction
When you are building your data model, you want to find the different things in your brainstorm that are alike. A recent example one of our users ran into was how to organize her cities, states, countries, and territories. She wants to describe a particular type of building based on which city it is in. There could be buildings in hundreds of different cities, so navigating this long list of potential locations could be difficult. Say you are adding a new building and you need to select the city it is in. Do you want to see a drop down box with 400 cities in it? Or do you want to select the country first and then the state and then the city? Might be a little easier right?
So there are two approaches to abstract this set of information. Your things are City, State, Country, Territory. What are all those things? How are they similar and how are they different? What properties do they have in common?
Well, cities, states, countries... they are different sizes. Different geographic locations on a map, based on longitude and latitude. Cities are inside states, which are inside Countries. In general, they are all Locations. They all have a name, Tulsa, Oklahoma, USA, North America. In this type of data model, you could say, "Countries contain states contain cities contain buildings." Uh oh... there's a lot more information about a building that doesn't really apply to a city though, right? A building has a number of floors, it's made of brick or wood or steel. It's a commercial building or a residential building. So we might not want to include buildings in the group of things we call "locations." If we did, then there would be a lot of cities with extraneous fields on the page when you go to add a new one.
So how do we represent these locations and buildings in our Situational Application? The first approach would be to create a City table, a State Table, and a Country table. Then, we create a building table and link it to the City table using what Qrimp calls a "Pick From." Pick froms let you pick an item from a big list of items. You want to pick one city for this building out of a list of 400 cities.
Other names for pick from could be foreign key (Relational Database), drop down list (Visual Studio), Value List (FileMaker), select box (HTML). They're all the same thing. They are represented on forms like this:
When you create a pickfrom in Qrimp, it'll build that form field for you automatically.
Another way we could describe this kind of information, this location information, would be to group them all together into one table, a locations table. A locations table would include a Name, maybe a description, and even a type of location: City, State, Country, or Territory. These things, these location types, then become their own table. When you add a new location, you choose the type of location from a select box as well. Your application may or may not be concerned about what type of location it is, or maybe it does.
If we use this single Locations Table to represent all of our locations, we get some neat functionality. We can represent it in a TreeView and drill down. Like this:
In that Tree View of Locations, if we click on New York City, on the right hand side in the related data section, also known as the right hand rail, you'll be able to add new locations or building by clicking the add links. Here's a screen shot:
Data Modelling is an Art and a Science
Data modeling is not an exact science, because have to make choices about how to build our data models. The Paradox of choice is that is makes us freer, but it paralyzes us. Don't let the number of options paralyze you, just do it. It doesn't have to be perfect. If you need help, email Qrimp Support, we'll help you decide. We've built hundreds, if not thousands of data models.
Data modeling is an art. Different expert database administrators will have different opinions about how to build a data model for different types of information. There are hundreds of data models for customer relationship management (CRM) systems alone.
There are pros and cons to different approaches. Some factors in these decisions include the kind of user interface you want to build on top of the data, performance issues and normalization, flexibility of the application, and other issues affect your data model.
Data Modeling takes a lot of experience and practice and you are going to make mistakes. Qrimp makes it easy to change your data model, so Qrimp is a great tool to experiment with. Qrimp builds most, if not all, of your User Interface automatically. Understanding how your data model will be presented will help you decide how to build the data model itself and this understanding takes time and practice.
In the next installment of this series, I'll show you how to take an abstracted description and actually build something to store that information in Qrimp. My suggestion to you is: Experiment. Build a simple model and then enter some data. Is it smooth? Is it easy? Does it make sense? Will it make sense to your users? If it doesn't, then build another model to represent the information in another way and see if that is more intuitive for you and the people who will be using your situational application with you.
In this video, Tim Berners-Lee, the inventor of the World Wide Web, argues for more raw data on the web. This video really struck a chord with me, because what he is arguing for here was one of the driving forces behind the Qrimp Platform. I'll talk about how Qrimp enables what he is describing and makes it easier for organizations to provide their data in the format he wants.
It's really important to have a lot of data
Data is the driver behind every Qrimp application. Qrimp makes it easy to input data. Qrimp makes it easy to get data out. You can use any REST api to get out any data in your Qrimp app. You can get it in CSV, XML, JSON, RSS, or any other custom format you create to interact with consumers of your data.
Having lots of data is critical. Lots of data about customers will help you understand which ones are happy and which ones are not. It will help you understand why and how to make your customers happy. It will tell you where your company has come and help you better understand where it is going.
The first step is getting the data into the computer. If you are stuck with paper or email or some other unstructured format for your data, it's more difficult to analyze later. Get lots of data.
Linked Data
Qrimp is built on top of a relational database. If you have customers and those customers make orders, then when you click on a customer, you see on the right hand side of your browser, the orders belonging to that customer. You can click the "Add..." link to add another order and it will automatically be linked to that customer, or you can select another customer to link it to.
These relationships between items in your database are critical and Qrimp makes it easy to manage them, view them, build reports around the data and more.
Those HTTP things...
Those HTTP thing are the pointer to the linked data. They are the link. For example, if you want to link to a particular customer, you create an http thing that looks like this: http://yourapp.qrimp.com/customers/Acme+Inc and then you have a link to your customer called Acme Inc.
Perhaps you want to see a list of your customers, you could build a more complicated url like this: http://yourapp.qrimp.com/db.aspx?t=customers and that would show the entire list of customers. If you want to see those customers in an excel spreadsheet, build a link like this: http://yourapp.qrimp.com/db.aspx?t=customers&vid=csv That vid describes how you want to view the data, in this case, you want to view it in a CSV format, which launches Excel when you click the link.
You can even build really complex queries that will give you a list of customers in a particular city: http://yourapp.qrimp.com/db.aspx?t=customers&city=Seattle
Pretty easy isn't it?
The web lets you put all kinds of data up there
So does Qrimp! Qrimp doesn't limit the kind of data you can put on the web. It can be business related or personal. Really, the more data we have on the web, the better. Personal data is important to businesses and business data is important to people.
Of course, some data is more private than others. You might not want some people to see some of your data, but that's why we make it easy to secure it and limit who has access to your data.
You don't want to let your database go until you've made a beautiful website for it
Unfortunately this is all too true. But your data does not need a special interface. It needs to be accessible. It needs to be browsable. One Qrimper has created a list of data and put it up there without doing anything special to the interface. I believe the consumers of the data, those who want to see the data, care less about what the web page looks like than they do about seeing the data itself. But, if you want to put a pretty interface on top of your data, Qrimp makes that easy too.
Check out what one Qrimper has done without changing the look and feel of his Qrimp app at all: http://scripturetunes.qrimp.com. That data is up there and choir leaders from all over the country can get ideas for songs they too can sing and teach the choir. If that Qrimper had waited until he had a totally custom interface for the data, how many people who have used his data already would have been left waiting for ideas for songs?
Don't wait. Get the data up there. You can make it prettier as you go! I could even argue that it is due to all these pretty interfaces that the web is so hard to use. Every website has links in a different place, they have different menu structures, the search box is in a different location. I do understand that it is through the appearance of our data that we "stand out," but it also makes it more difficult to use the web in general.
Remember, all things being equal, it is the content of your website that is important. If your website looks great, but no one can find anything or it is difficult to use, then people won't come back. Focus on the data first, then what the data looks like. You'll learn over time how to make it easier to visualize.
Raw data now!
It is the raw data that is important. When you go to a car dealer and ask how much a car costs, if the dealer packages up the price into lots of long sentences and explanations and talks about the features, do you get frustrated? Yes, of course, because you asked for the price of the car. The price of the car is the Raw Data! You want the price, you don't want a picture of the car and a fancy border around the price with some particular font -- you want the data!
Now, imagine if you could go to your car dealer's website and pull down a list of every car on the lot, the make, model, and year of the car, what color it is and a list of all the options in raw data without having to hunt through some fancy interface to find that information? You could sort by price or filter by make. Wouldn't that be easier than having to view each car independently and click on the link to drill into more details about the car on yet another type of page?
Give us the RAW DATA!
No more excuses!
In the past, it was difficult to go from the raw data to the web. You may need a database guru or a programmer. Well, not anymore! Not with Qrimp, just upload your raw data. Copy/paste from excel right into Qrimp and your raw data is available immediately! Qrimp puts a nice interface on it. You can filter by any field, you can import into other applications, you can mix and match it across other data sets.
Unlike other blog programs that focus on making your blog pretty, I didn't have to do anything special with Qrimp to be able to provide the data in those different formats. All those different formats come standard with every Qrimp app. Imagine if all the data on the web was as easy to access and use with other programs as data inside your Qrimp app!
Want to get more serious
How many articles have you read about cancer and heard a statistic like this: 25% of Americans get Cancer. Does that tell you anything? Which of those Americans got cancer? how old were they? How tall were they? Did they smoke? How much did those Americans with cancer look like me? Perhaps I am in a demographic that never got cancer!
How can we know that without the raw data? If we had an excel spreadsheet that listed all the different properties of people who got cancer, we could filter that list to include the properties we have. We could see how likely it is to get cancer at a particular age, or if we frequently drink coffee -- or don't! We could model our lives after those types of Americans, or any other country's citizens, don't get cancer.
Why do Japanese people live longer? What is common, or not common among Japanese people, compared to people from other countries. Without the raw data, it will be difficult for the average person to know. We are left to sound bites and articles in the newspaper geared to the population at large -- not each of us as individuals.
In this post, I'll describe a simple customer extranet. Perhaps these thoughts may help you design your own extranet. I will also construct a module based on the resulting application, so you can quickly add the result of these posts to your own Qrimp application.
In the example below, I will indicate some of the items that are People with Bold, Processes with Italics, and Things with Underline. Sometimes the item may be a Person or a Thing and will appear like Customers.
Customer Extranet Brainstorm
I want a system where customers can log in and check on the status of their custom projects. Before the project gets started, they contact us and ask if we can help them solve a particular problem. Different customers have different skill levels when it comes to technology, so they need different amounts of help to get started.
After customers create their project brainstorm, we will break down the brainstorm into sentences that correspond to individual items of work. We describe how complicated each unit of work is, how long we expect it to take, and how much it will cost to implement. The customer should be able to organize the items of work into iterations and prioritize them based on budget and system requirements.
We like to allow the customer to choose in an a la carte fashion which items they want now and which can wait. Like a shopping cart, the customer can add each item to a basket of tasksgrouped into different phases of the project. Each phase may have several iterations. A phase could take a month and have 4 iterations for example.
During this time, we may have one or many meetings where the customer where we can askquestions and elaborate on the requirements where there could be confusion.
(Note to the reader: As an exercise, find the People, Processes, and Things in the rest of this brainstorm)
After the customer has chosen which items he or she wants to implement first, we send out an invoice for the first half of the project payment up front. When we receive payment, we begin work. The customer can log in while we are working and check on the status of each work item. The customer may want to know who is working on the item and communicate with the developer via messages.
When the iteration is complete, we should test the functionality and indicate any bugs we find or issues related to the item. Then we notify the customer that the iteration is complete and the customer logs into the application we have built to verify that it works as desired. If it doesn't, the customer can add an issue to a log or a bug report indicating that something needs to be changed. Sometimes the changes are within scope and sometimes they are out of scope, so we need to be able to indicate if something the customer may have thought was a simple change or perhaps we should move it to another iteration or phase.
When the customer is satisfied that all the work has been completed satisfactorily, we send out the invoice for the second half of the payment. We should let the customer see in their view of the extranet which payments have been received.
The customer should use the application for a little while before we begin the next iterations so that any ideas gained or issues found related to the previous iterations can be accommodated in brainstorms for future iterations.
Post Brainstorm analysis
As we dig a little deeper into the project brainstorm, we start to notice different kinds of verbs. For example, in the sentence, "Different customers have different skill levels..." The verb have is not in italics. It is a verb, but it is not an action verb, it is not something customers do, but rather something that describes a customer. These things that describe other things are what we call Properties. Perhaps one customer is skill level 8 and another skill level 4.
In the previous post on Designing Situational Applications, I talked about putting the Things in a chart with their properties. In our extranet, a customer might be in a chart that looks like this:
Customer Name Description Skill Level Email address
You may be wondering at this point, "Why does skill level matter?" Maybe it doesn't. Or maybe if we know the customers' skill levels it will help us communicate with them better. Maybe we can use skill level as a progress meter for our customer to help them see how much they are learning and give them an incentive to learn more. Remember, the goal here is not to be perfect with your description of the system, but to write down anything and everything that you think of.
There may be more users of your system than just you. This brainstorm is the beginning of a conversation between you and the developer (who may also be you). Anything that is left out at this very early stage could be more difficult to accommodate later, so it's best to get everything out as soon as possible.
Let's look at another sentence in detail, "We describe how complicated each unit of work is, how long we expect it to take, and how much it will cost to implement." Can you find the Things and properties for those Things in that sentence? Hint: Describe is a Process. Describing something usually involves typing out a (you guessed it) description of something. Typing out this description is part of a larger Process of Creating a unit of work. A unit of work is also a task, which is a more common and understandable term, so let's use that.
Here is a chart for a Task built from the sentence above: Task Name Description Complexity TimeEstimate Cost
Can you think of other properties of a task? Reread the brainstorm and consider these questions: Who is the task assigned to? What is the status of the task? Has it been completed? How does the task relate to other Things in the system? Are there any bugs or issues related to the Task? Does it require rework? Is customer satisfied that the task has been completed as expected?
As an exercise, write down all the People, Processes and Things in the brainstorm above. Put the Things in a chart with their properties. In the next post, we will begin to draw out some of these items and get more detailed.
You know you need some software or a web application to help you solve a problem, but how do you get started? This series of posts will walk you through the process from idea to building the situational application.
If you are new to Situational Applications, you may want to check out Jonathan Sapir's soon to be released book, Power in the Cloud. I had the privilege of reading the final draft and it's a good read if you want to help push your organization in the direction of better information management.
In this series of posts, I'll take an informal approach to designing Situational Applications. The goal is to help you understand your information problem better and break it down into manageable pieces that you can then construct with your development environment or Application Platform. Qrimp is an example of such a situational application platform.
Most information management systems center around three things: People, Processes, and Things. Before you get started building your application, writing down everything you can think of related to these three topics will help you capture everything that your application will need to do. That doesn't mean you are going to build out all of the functionality that you describe, but the more you make concrete before you get started, the better you'll be able to plan your attack. Think of it like you think of a business plan for your company. It is a plan for building a system that helps you manage some part of that company.
Situational applications connect People to Things and help them manage the Processes that keep everything up to date and move information through the system.
The People are the users of your system. They log in, they search for information (things) and they perform actions in the system (Processes). They can see Things, or parts of things, based on who they are and which roles they are assigned to. When thinking of the people involved, sometimes it is easier to think of them as individuals and sometimes as their position within the organization.
Once you know who will be using your system, write down each role on one line of a piece of paper or in a chart. One line for each will help you draw lines between them and the Things and Processes later. These lines and relationsips will show you how the different parts of your application work together.
Some examples of people who may use your situation application are: Hiring Manager, Customer Service Representative, Tech Support Agent, Sales Agent, CEO, Account Manager, or Librarian. Each of these people will work with different things through different Processes, i.e. functions they perform.
The Things in your situational application correspond to the data you want to store. If you are building a Customer Relationship Management (CRM) system for example, some Things will be: Customers, Accounts, Interactions and Support Requests. Again, on a piece of paper, scribble down all the things you can think of related to this particular problem you are trying to solve. Put them in a chart, with the name of the thing at the top, then below it, list different properties of the thing like this:
Customer Customer Name Address City State Zip Phone Number Notes
Customer Contact Customer First Name Last Name Email Address Phone Number
In future posts, I'll talk about how to determine relationships between information. In the scenario above, you might imagine that a particular customer has more than one contact. You talk to a contact in Accounts Payable when you want to get paid and you talk to the decision maker about selling them additional products or services.
After you write down all the Things, draw lines from the People to the Things they can see or can't see if that will be easier. This will help you define security settings for your Qrimp app. If there isn't enough room for lines, use a color coded system of circles or check boxes to indicate which People can see which Things. You can even get more detailed and talk about who can Create, Read, Update, and Delete each item. On the lines you've drawn, add a C, R, U, or D.
The goal here is less about being neat and formal and more about getting the information out of your head as soon as the ideas pop into it. Try to write down more than you think you may implement. In subsequent posts, I'll show you how to take these thoughts and make them more organized, and order them based on priorities and difficulty to implement. You want to build a system that can do as much as possible quickly, then add to it later. What we want to do is identify manageable chunks of the application that make sense to be built together in different iterations. You can read more about Iterative Development at Wikipedia.
In general, Processes correspond to verbs and Things correspond to nouns. Above, we mentioned talking to our customers. Talking is an example of a Process. You will want to make note of any Processes that come to mind. A process is something that happens. It's a description of how information moves through your system.
Let's stick with the CRM example. In a CRM, a common process is the Sales Cycle. Between the time your potential customer is a lead and the money is in the bank, many different people in your organization may talk to the person to get more and more information that will help you solidify the customer relationship and determine the best products (another example of Things) for that customer.
Employees and applicants are Things in many Human Resources applications. Candidates apply for jobs, their resumes (Thing) are reviewed (Process), they are interviewed (Process) on the phone (Thing) and in person, and eventually they may be hired (Process). At this point, they become employees. Employees (People) have benefits (Things) and complete (Process) performance evaluations (also Things).
Remeber, Processes correspond to verbs (what people do) and Things correspond to nouns (the object of the verb). You can also think of the People as the subject of the sentence, "Bob (People) searches (Process) for the Customer Account (Thing). Then he adds a note that he talked to their Accounts Payable Contact." As an exercise, find the People, Processes, and Things in the last sentence of that quote. I'll include the answers at the bottom of this post.
Getting Started
I had a conversation today with a potential client who asked if we could help him build a system. To get started designing the system, I recommended sit down and start typing out everything he could think about the application and I recommend the same thing to readers. Don't worry about grammar and spelling, just type it out as fast as you can think of it. The goal is to get infromation out of your head so it can benefit you later and other People soon.
When you are finished, circle all references to People (users of your application), Things (nouns) and Processes (verbs). It may help to use different Ink colors or shapes to differentiate each category of item in your application.
In my next posts in this series, I'll create a sample brainstorm and highlight the People, Processes, and Things. Then, we'll map those items to concepts in a Situational Application and build the sample system.
I hope this will help walk you into your application. I know in the beginning, it's difficult to get everything out of your head. It won't all come out at once and as you build and use the system, it's almost inevitable that you'll remember things you forgot and have to make some changes, but that's why web platforms are so great for solving problems quickly -- changes can be made easily as you learn more about the system.
What were the People, Processes and Things in that last sentence? "Then he adds a note that he talked to their Accounts Payable Contact." He was Bob (People). Adds and talked are Processes. Note and Accounts Payable Contact are both things.
In our continuing effort to support Coghead customers, we've developed an import tool that will allow you to enter your username and password and then download your data directly into your Qrimp Application.
Here's a simple howto that will walk you through using the Import Tool to pull in your Coghead data.
Step 1: Go to the Coghead Download Type download.aspx after your application name. Something like this
http://yourapp.qrimp.com/download.aspx
and you will see the Coghead download page.
Step 2: Enter your Coghead Username and Password
Step 3-5: Browse to your application
Step 6: Select collections to import
After selecting the application to import, you will see a list of data collections in the Application. Please note that Qrimp uses the standard database term "table" where Coghead uses the word "collection."
After importing the collection, you will see a list of imported records and a link to download more collections. Qrimp automatically adds a menu tab so you can see your data easily.
After importing, Qrimp preserves your data relationships. We are going to clean up the appearance of our data in the next step.
Step 7: Set default fields After importing your data, you can view the records by clicking on the tabs Qrimp creates for you automatically.
You'll notice that the CGRecordID is there to show the record identifier. If you do not need this field, we suggest deleting it, or if you may need this field later, hide it using column level security. Let's see the same record after we have deleted all our CGRecordIDs. Click to zoom
After we delete the CGRecordID, our Qrimp app looks more user friendly:
After importing your Coghead information. A few more minutes configuring security, menus, and a little bit of field layout and you will be ready to use your imported Qrimp app.
Of course we are here to help you through this process. We're looking forward to working with you! Call to speak to a live human being: US (972) 930-0629.
The Qrimp team was saddened today to hear that one of our collaborators in the Platform as a Service (PaaS) space is no longer with us. We want to offer our sincere condolences to the staff. This must be a terrible time for them.
For their customers, life goes on and they need a solution fast.
Alternative to Coghead
We are offering 3 months free, support, webinars, and assistance to existing Coghead customers through a promotional offer. This offer is available to existing Coghead customers until April 30, 2009.
To take advantage of this offer and get Qrimp at a 50% discount for 6 months off the current price, click the PayPal button below.
Exact terms of the offer:
Free for the first 3 months
Then $25.00 USD for the next 6 months
Then $50.00 USD for each month
We will do everything we can to make this transition as easy as possible. Qrimp is an excellent Alternative to Coghead, we think it is The Best Alternative to Coghead.
Talk to us about Pricing
Our goal is to meet or beat your current Coghead subscription costs. If you show us your monthly costs for a particular application, we will take 10% off the Coghead price.
Call now: US (972) 930-0629 We would love to talk to you about how we can help you solve this migration problem.
Subscribe