vlag
vlag
Heb je
een vraag?

info@cuurios.com
085 06 08 400

Do you recognize the value of your data?

Auteur: Gaëtan Giraud
juni 2020

Every company works with data. Productivity, prices, stock, you name it, anything that makes its way to the next report and helps you take the next step – just numbers. Chosen the right strategy, you can make these numbers work for you.

A case from the trenches

We dedicated the previous blog post to the value and importance of your data. You might already be intrigued to imagine how those numbers can save you a lot of work and even make your company more successful or “just” simplify your decision making process. It’s time to do something about it.

But then what? It might be very tempting to go for the new and shiny, to start an Artificial Intelligence (AI) project because that is the future and you are afraid to miss the boat. But AI requires a very high digitization maturity and work best on very specific use cases.

The technology has some known drawbacks, requiring large amount of (mostly labeled) data. It also lacks in so important auditability, a real and valid concern for many business leaders.

Focusing on this far-way horizon may lead you to over-reaching, over-spending, and might actually backfire. Lacking in tangible results to show, it could reduce the willingness to invest in data and data technologies. You will miss the low hanging fruit that will add value to your business and will help champion data in your organization.

Through a real use case at one of our customers, I will try to explain how we managed to integrate data and create value by integrating a use case that mattered.

The use case

This customer is responsible for the operations of multiple industrial sites, each producing 24/7. At the beginning of the day, engineers gather data, calculate, and analyze the shortfalls in production from the day before. What was the reason, was it planned, what can be done about it, will this impact our overall production, etc.

This data needs to be revised and approved by the operational and reporting team and reported officially to management.   

Until very recently, they would extract data from their process data historian, process it through an excel sheet and pretty much run the process by hand using the Microsoft Excel.

A repetitive and error prone process, with little value in the data wrangling. A perfect candidate for automation!

To support this customer, we deployed a solution that would:

  • Fetch the data automatically from the OSIsoft PI data historian
  • Run an algorithm to detect production shortfalls and faulty input. The algorithm tries as well to infer the cause of the production shortfalls from previous related cases.
  • Present the results in a Web UI, including history and raw data
  • Present the detected production shortfalls to engineers and operators for analysis and validation
  • Extract the results into the right format for exporting to the reporting system

Now, engineers and operators can come to the office in the morning, and the data about the production shortfalls will be ready for them to analyze and validate, resulting in:

  • Less work intensive process
  • Better accuracy 
  • Easier analysis based on charts 
  • History of production shortfalls under your fingertip

Since the first version, we keep refining the process, adding new algorithms and new mechanisms to streamline even more of their operations (For example, producing production reports automatically from the production data)

What can we take from this?

The algorithm for analyzing production data is not based on machine learning or fancy AI techniques. It is a regular algorithm designed together with the process engineers.

But it delivers exactly what the customer wants and provides tremendous value to the business.

While running complex machine learning algorithms might add some value in the future, focusing on them right from the start would have diverted us from what we really wanted to achieve:

Providing the business with value!

Contact de auteur
U kunt deze blog delen

Meer blogs

Curiosity and result-centricity a.k.a. what drives a technology pioneer – Meet Cuurios’ co-founder Gaëtan

Being a teenager in the 90s, with the internet, mobile phones and all sort of exciting new technologies coming up, it was hard not being enthusiastic about Computer Sciences!

After finishing my degree (Computer Science and Networks), I took a detour, working as a consultant, busy with the soft side of IT (writing design documents, requirements, sketching business and IT processes, these sort of things). After a while I realized that I wanted to go back to the core of technology and changed focus towards more technical and code related work.

The real joy in coding for me is creating something out of your brain, and see it come to life - something most programmers would recognize. In addition to the creative thinking and joy of creation, computers follow straightforward logical patterns, what you code is what you get. Refreshing compared to working with humans (Not that I have misanthropic tendencies, but hey, everyone will agree, people can be difficult ;) ).

I am result-driven, inquisitive, and professional, always curious, and ready to learn new technologies as well as dive deeper in what I already know. I love challenges and new discoveries, which makes my field as a professional really broad. I do not like to fit in a box and am eager to always keep learning! So, java bytecode, deep learning, graph databases, SQL, high level architecture ontologies, web technologies, security, networking, bring it on! :) .

My Cuurios-story

I am one of the owners, Cuurios is my baby. As a child of the first internet bubble, of the Amazon and the Google era, being an entrepreneur has always been one of my deepest dreams. You can see it as an extension of the coder’s creative drive. Thinking out, designing, and developing a visionary product and bring it to market, full control, and total responsibility. Daunting, yet exhilarating!

As owner and lead developer Cuurios gives me the possibility to completely give direction to the work, according to my own ideas, and to where I want to go. It also gives me the freedom of setting my own agenda and being able to work as I wish – probably every thriving programmer dreams about that at some point.

In addition to that, I believe Cuurios does not only hold value for the owners or the employees. We aspire to deliver real values to our customers, always helping them to get the most of their experience with us – not just with our products, but also every level of our communication, every step of us working together. We are very proactive, and we tell it how it is, we can expect no bs from us!

YES!Delft: Investor readiness program – A partial view

After a first month as part of the YES!Delft investor readiness program, it is time to share some thoughts on the process, what we’ve learned so far and how it impacted us.

DISCLAIMER: This light-hearted description is only very loosely based on reality and should definitely not be taken at face value :-)

Like most, we started this journey as enthusiastic entrepreneurs, completely sold on our ideas, focused on how great it is and all the cool stuff we have in petto, the myriad of functionality it will provide and how it will revolutionize the market. We were pretty confident, sure of our game.

Then we had 1 minute to pitch.

Big Fail

  • Everybody understood we had something great, nobody could quite get what it was all about.

Investors are from Mars

That would be the first thing we learned. Pitching to an investor (or a prospective client) is not about YOU, it’s about THEM.

Investors speak the language of TAM, SAM, SEM, ROI, Churn, Business Models, Valuation, EBIDTA, Cash Flows... Learning the investor’s lingo was a damning task, like learning a second language full of acronyms and numbers. Frustrating at the beginning, very enlightening in the end. It really helped us get our story straight and forced us to do the math. Cause you’ve got to do the math. You can’t stay forever in the fluffy stage.

The first hurdle passed, it was not the end of it. We had some numbers, great, but what was it again that we sold? And, most importantly, sell to whom?

  • Ok, you’ve got 30 seconds.

Hmm, yes, you know, we make software that does stuff with data, and it’s super cool.

At this point we knew we had to do something about that elevator pitch. 

Elevator music pitch

Here comes the WOW method in place. A simple method to get your ideas straight and write an elevator pitch with a true WOW factor (yes, it is in the name).

Suddenly, it all made sense. This is the story we want to tell, these are our customers, and this is what their pain is.

Elevator pitch much improved, still some way to go, but at least most people now understand what we are trying to achieve.

No free lunch

Now that we’ve got a good enough elevator pitch, and some numbers, time for what we’ve all come for: Show me the money!

Again, a good learning experience: there is nothing like a free lunch in this world. Investors are not charities, they’re in for the big bucks! And how to convince them that you are the next Google when you are a fledging start-up?

  • Get some customers on board, build traction, show you’ve got it!

But wait a sec, to build any sort of real traction we first need to finish up our product! And wasn’t raising money supposed to help get us there? It seems a bit like a chicken and egg story, isn’t it?

Welcome into the real-world people!

There are some options fortunately, government grants and loans, to help you get started and get you through this first stage in your development, without of course forgetting the most common investment of all, some good old-fashioned hard work!

Conclusion

So far, a very valuable program, it has helped us to sharpen our message, build up our case, and get us ready for the next stage!

From theory to reality: internship at Cuurios – Meet Bram

Part of my final year of international business at The Hague University of Applied sciences is to do an internship. During this engrossing year I was lucky enough to do my internship here at Cuurios. I have followed almost every business related subject during the last 3 years at my university, ranging from human resources to finance to operations management. I always missed a really tech related subject which is quite important in the modern days. I’m really happy I can fulfil that missing piece here at Cuurios.

I applied to do my internship at Cuurios because it is a relatively young, still small sized but growing company. I like this size during this internship because even though I am an intern at Cuurios I am also part of the team and I am really responsible for the tasks assigned to me. Although the pandemic has made us work from home most of the time, I am still able to get proper guidance and plenty of sparring opportunities.

Whilst I’m doing my internship here, Cuurios participates in the Investor readiness program by YES!Delft. It is a really interesting program where I get the opportunity to translate gained knowledge from my study into reality. I help Cuurios to prepare for an acceleration of their business, this ranges from a good company value proposition and pitch to a financial planning and business plan. The tasks are diverse and I’m able to work however I feel best suited while still being coached and questioned which I find is working perfectly.

"Programming is not a task, but a hobby" - Meet Michael

For me, programming came in late. I wanted to be a lawyer, I had graduated high-school with all hopes of studying law, but a light shone and a voice called out to me - “Michael, study Computer Science instead”. I then honoured the call and started preparation to get admission into University to study Computer Science. Thankfully, I got in.

In my first year (2012), I was introduced into the art of programming.

The idea of me building something for people to use was similar to being given a magic wand, which felt very good. I started experimenting with Visual Basic, the drag and drop system helped me easily visualize my ideas.

Year after year, I delved deeper, building applications for friends and small organizations. Everything changed when I was paid to build an application in my third year, a holy grail was given to me. I didn’t know people would pay you for what you enjoy doing most. It was an eye-opener.

To me, programming is not a task, but a hobby, and creating things is wired in my core. I became a frontend web developer because it’s the closest programmable bit to the user (had not discovered Product Design at that time) and I enjoy that feeling of being able to engineer experiences for users whilst controlling what they see and how they use the application as a whole.

As humans, it’s pure happiness to see people follow you. In programming, it’s the same feeling, if not more when you see metrics of the people that depend on what you build. I like the influence, though little, to control how people carry out their daily important business, leisure or personal tasks using my applications.

My Cuurios-story

I joined Cuurios in October 2018; a very good decision I must say. I applied because I wanted to learn how things are done in other companies, and Cuurios’ “Data to Actions” tagline sounded like a place that would boost my programming knowledge and nudge me to code more complex applications.

At the very beginning, my first project gave me sleepless nights, as I didn’t understand most of the application. I bought whiteboards and started disintegrating the project to understand the whole quite-complex system. Now, however, I have gotten a better grasp of working on complex systems, my frontend skills have improved dramatically. The best decision so far. I feel my role in Cuurios is important (very much to me), I control how and what the customer sees. Though you need to have a very keen eye for design to do this and Cuurios has enabled me to perform this art efficiently, even using my little Product Design skill. Although I cannot single-handedly add a button anywhere I like, but I can make sure the button sits where it can be easily accessed.

At Cuurios, every ticket is like a HackerRank question, especially when it comes from Leen (COO). Sometimes I’d have to read and re-read to be able to digest the problem and think of a suitable solution which has improved my problem-solving ability. I ask questions a lot and that has helped me grow. In addition to that, Gaetan’s (CTO) experience has made me a better programmer. I take time to study the codebases of the applications built. (When you learn from the best, you become like them).

I also wonder sometimes, how Leen does it, that he is everywhere from a business standpoint. I’ve learnt from him that you need to understand the customers’ request in-and-out.

I believe Cuurios is a place to be to sky-rocket your career and build fantastic projects, and most importantly everyone at Cuurios is human.

Work as you're used to: tailor-made domain representation with graphs

One of the common issues we face when developing applications for industrial customers, is the issue of accurately representing their domain.

A domain is the set of assets, equipment, departments, systems, that make up the whole of a company’s operations. Organizations usually have fine grained definitions of who should be responsible for managing a specific asset, which department resupplies systems, etc.

A software system should integrate with an organization structure and enable its operations. More often than not, they achieve the opposite, requiring organizations to fit their processes and structure inside their own rigid asset structure.

While promoting standardization, this approach stifles organizational innovations. It leads to faulty and incomplete domain representation, as assets are not recorded as they are, but as fit the system, or not recorded at all. In the end, many systems end up being hacked by system-integrators or in-house teams to make them fit, or a custom solution is being developed.

Very often these limitations are driven by technological limitations, SQL databases (still the norm for most industrial applications) requiring a rigid structure to be performant.

Graphs

We think that domains can best be described using graphs. A graph is a representation of information using node (vertices) and links (edges).

The following example should help to shed some light on the concept, and explain why we think it is such a great fit for representing domains:

  • Company A operates a small plant.
  • The plant has systems, composed of equipment or sub-systems. An equipment or a sub-system can be shared by multiple parent-systems.
  • At the same time, each equipment is linked to 2 departments, the maintenance department, and the production department.
  • Each equipment also has supervisor, a specific person, and a back-up supervisor pool, a pool of people that can be called up if the supervisor is unavailable.

Now you can see how this would start to be very complex when designed in the traditional fashion, leading to complex and inflexible implementations.

Now look at how we could implement this using a graph:

Sneak peek: this is how we build software at Cuurios

A couple of introverts sitting in front of multiple dark screens with green or white texts running on each, typing with untraceably fast fingers, only the keyboard clacking breaks the silence...

Although during the last decade the perception of programmers may have changed: instead of mom’s basement, they are now imagined in a fancy, futuristic, well-equipped environment, the basic personality traits of geeks are still perceived the same.

Just typing, and typing all day...

... well honestly, no. As software developers we spend most of our times with designs, research and problem solving. We could actually sit down and start writing your application the second we got the assignment, but that’s not the effective way. You want good, steady result, fast, and there is only one way to that: design, plan, research, and finally code.

Yes, we can type fast. Yes, we can sit in silence and focus for 8 hours without so much as taking a lunch break – or at least some of us can. Yes, we are coding in the evening, in the weekend, in our freetime, even in our dreams sometimes – because we LOVE solving problems. Give us the most complex ideas, the impossible tasks, and we will trigger happy, and start working on them straight away.

Yes, we ARE geeks, but that doesn’t make us mysterious, unapproachable, introvert or unsocial. We can easily come across arrogant, but most of the time it would just take forever to make you understand the details – we don’t have God complex, we just know, that it’s better to get it done, than explaining how will we get it done.

We adore technology and advancement!

I mean, there is probably no surprise there, but we love to surround ourselves with the latest technological advances – be it about our physical surroundig, or our codebase. So we research, we read, we learn. We get familiar with new frameworks, libraries, advanced solutions every day – then apply our newly acquired knowledge in your software, making it better, stronger, faster, safer.

How do you recognize a good developer?

Now this can be hard – as a person not knowing anything about software development, how can you tell, who will be the professional skilled enough to get the job done?

The good news is, you don’t need technical knowledge to make that decision. Good professionals stand out. Not by having millions of frameworks listed in their CV-s, not by having multiple years of experience – although that is not a bad thing –, not by asseverating they are the best, or the only ones who have a solution for you.

Good professionals stand out, because they are enthusiastic and passionate. They simply love what they are doing, they are able to switch to problem solving mode, and even start braimstorming with you to enhance your ideas as soon as they understood your needs. They are perfectionists, simply because they want to be proud of their making, and give it the best they can think of.

„Okay, but what about the sneak peek?”

And yes, here we are, after all this talk about what developers are not doing, let’s see how we at Cuurios actually turn your idea into software, so next time you work with a programmer, you will have a better understanding of what we really do [1].

  • Driven by curiosity we listen carefully what you want and challenge what you need.
  • We read the documentation, getting a nice, overall picture of what you need.
  • We read the documentation again, going into details, stop here and there for a second, making notes.
  • We just sit and stare. Now this might look like we are not doing anything, just staring out of the window, waiting for the day to end, but this is the part where at least 20% of the work gets done. We write and design the whole application in our head, tracing our steps, making mental or actual notes, connections, stripping the whole use case down to logic, numbers, actions, and finally breaking it down to parts.
  • We read the documentation again. I know, by now we should know by heart, right? But at this point, we make notes, create diagrams, start researching for the best solution, the latest technologies, the most useful libraries.
  • Brainstorm. Yes, programmers rarely work completely alone. We use our colleagues recommendations on solving similar problems they encountered, share our experience, and learn from eachother. Even if this happens online.
  • Depending on the duration of a project, we prepare the sprints, or the first couple weeks at least, read the documentation one last time (I know, right?), include every little detail in tickets, organize the workflow, then get started with the typing all day...

From here on out, we do the same routine every day – although it’s never the same and never gets boring:

  • In the morning, we prepare for the day. We go through what we finished the day before, decide on and preapre for the next steps.
  • A daily scrum meeting keeps us accountable – also a very good place to see if someone got stuck, needs help, or just a different approach or idea to get out of a deadlock.
  • During the day: design, research, code, test, debug, finalize, repeat. For each and every small part of the application, until we get a result we would proudly present.

Good software developers take pride in their work. They don’t just enjoy creating solutions for you, they are just as happy – if not even prouder and happier – as you are, when you start using what they made for you.

[1] The working method described here is Cuurios-specific, other companies and teams may have different ways to divide tasks and manage their workflow.

blog